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Abstract 

In  many  ways,  existing  languages  place  unrealistic  expectations  on  library  and 
framework  designers,  allowing  some  varieties  of  client  reuse  only  if  it  is  explicitly — 
sometimes  manually — supported.  Instead,  we  should  aim  for  the  ideal:  a  language 
design  that  reduces  the  amount  of  prognostication  that  is  required  on  the  part  of 
the  original  designers.  In  particular,  I  show  that  languages  can  and  should  support 
a  combination  of  structural  and  nominal  subtyping,  external  dispatch,  and  a  form 
of  multiple  inheritance. 

Structural  subtyping,  which  allows  new  types  to  be  added  to  an  existing  hier¬ 
archy  post-hoc,  has  been  studied  for  decades,  but  a  naive  combination  of  struc¬ 
tural  subtyping  and  external  dispatch  poses  serious  typechecking  issues.  Instead, 
I  present  a  novel  combination  of  structural  subtyping,  nominal  subtyping,  and  ex¬ 
ternal  dispatch — external  dispatch  allowing  programmers  to  write  new  code  that 
dynamically  dispatches  on  an  existing  hierarchy.  In  its  absence,  programmers  will 
often  resort  to  writing  manual  dispatch  code,  which  is  tedious,  error-prone,  and 
lacks  extensibility. 

External  dispatch  is  also  difficult  to  combine  with  another  useful  language 
feature — multiple  inheritance.  It  so  happens  that  any  form  of  multiple  inheritance 
(even  Java-style)  makes  modular  typechecking  of  external  methods  extremely  dif¬ 
ficult;  this  is  due  to  the  so-called  “diamond  problem.”  To  sidestep  these  issues,  I 
propose  a  novel  form  of  multiple  inheritance  which  does  not  allow  diamonds,  but 
recovers  expressiveness  through  a  generalized  form  of  self-types. 

Finally,  since  languages  with  structural  subtyping  are  used  mainly  in  the  re¬ 
search  community,  it  had  thus  far  remained  unclear  whether  structural  subtyping  is 
actually  useful  in  practice.  To  answer  this  question,  I  performed  a  novel  empirical 
study  of  existing  Java  programs,  which  found  that  (a)  even  nominally-typed  pro¬ 
grams  could  benefit  from  structural  subtyping,  and  (b)  there  is  a  potential  synergy 
between  structural  subtyping  and  external  dispatch. 
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Chapter  i 
Introduction 


“Where  shall  I  begin,  please  your  Majesty?”  he  asked. 

“Begin  at  the  beginning,”  the  King  said  gravely,  “and  go  on  till  you 
come  to  the  end:  then  stop.” 

Lewis  Carroll  (Alice’s  Adventures  in  Wonderland) 

1.1  Overview 

Existing  programming  systems  are  often  adequate  for  developing  software,  but  can  lack  sup¬ 
port  for  effectively  evolving  that  software.  For  example,  modifications  to  a  program  may  require 
changing  the  source  code  of  some  library  or  framework,  a  library  or  framework  whose  main- 
tainer  is  some  other  organization  or  team.  Even  if  the  library/framework  is  open-source,  it  is 
evolving  as  well — for  bug  fixes,  if  nothing  else.  As  a  consequence,  local  modifications  to  this 
source  code  must  be  manually  updated  when  a  new  version  of  the  library  or  framework  is  re¬ 
leased.  Unless  both  the  local  modifications  and  the  changes  in  the  new  release  are  minor  and 
localized,  this  approach  is  impractical. 

One  way  to  improve  this  situation  is  to  create  additional  programming  language  support  for 
software  extensibility  and  code  reuse.  Using  the  wrong  language  can  create  obstacles  for  code 
reuse;  some  varieties  of  changes  are  only  possible  if  they  are  explicitly  supported  by  the  code’s 
design.  This  in  turn  requires  that  the  need  for  the  change  be  anticipated,  which  is  unrealistic. 
Instead,  a  language  design  should  aim  to  reduce  the  amount  of  prognostication  that  is  required 
on  the  part  of  the  original  designers. 

Object-oriented  languages  provide  many  mechanisms  for  unanticipated  code  reuse;  for  in¬ 
stance,  programmers  may  code  against  an  abstract  interface  (allowing  new  implementations  to 
be  substituted)  or  may  use  inheritance  to  reuse  existing  code.  However,  existing  languages  place 
restrictions  on  these  constructs  (or  forgo  static  type  safety),  reducing  their  potential  utility. 

In  particular,  I  argue  that  languages  should  support  retroactive  abstraction,  external  dis¬ 
patch,  and  a  form  of  multiple  inheritance.  The  potential  utility  of  each  of  these  features  is  de¬ 
scribed  at  a  high  level  in  this  chapter  and  with  more  detail  in  each  corresponding  chapter.  In 
particular,  Sect.|3.6|and  Chapter|^present  real-world  examples  and  empirical  data,  respectively, 
as  concrete  evidence  to  support  the  claim. 
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Assumptions  and  Definitions 

Throughout  this  dissertation,  I  make  the  key  assumption  that  modularity  (in  particular,  modular 
typechecking)  is  essential  to  any  sensible  language  design.  A  typechecking  algorithm  is  modular 
if  no  link-time  typechecking  is  required.^  This  property  is  critical  in  an  runtime  environment 
that  permits  dynamic  code  loading  (e.g.,  DLLs,  dynamic  classloading),  as  such  a  static  linking 
phase  does  not  exist  in  these  situations. 

Additionally,  I  assume  that  more  static  checking  is  preferable  to  less;  i.e.,  catching  additional 
errors  at  compile  time  is  a  good  thing.  In  particular,  I  would  not  consider  “dynamically-typed” 
languages  as  providing  a  solution  to  the  problems  addressed  in  this  dissertation. 

In  this  document,  I  use  the  term  interface  to  denote  a  set  of  methods  along  with  their  types. 
Where  such  a  distinction  is  relevant,  I  use  the  term  nominal  interface  in  reference  to  languages 
with  nominal  sub  typing.  Note  that  this  definition  of  “interface”  differs  from  that  of  Java  or  C#, 
where  (nominal)  interfaces  also  have  an  associated  tag  that  can  be  used  in  dispatch  (via  instanceof 
tests  or  reflection).  We  refer  to  such  entities  as  “tagged  interfaces”  in  cases  where  the  distinction 
is  pertinent.  Note  that  “tagged”  interfaces  are  necessarily  also  nominal  interfaces. 


1.2  Limitations  of  Existing  Languages 

This  section  describes,  through  example,  limitations  of  existing  languages  that  can  negatively 
impact  code  reuse.  Though  the  problems  are  not  all  directly  related  to  one  another,  there  are 
interactions  between  them. 


Retroactive  Abstraction 


Sometimes,  programmers  wish  to  code  against  a  particular  implicit  interface  that  is  shared  by 
two  classes,  so  that  objects  of  either  class  can  be  used.  Unfortunately,  the  lack  of  retroactive 
abstraction  in  traditional  languages  makes  it  difficult  accomplish  this  task. 

Concretely,  suppose  we  have  a  Java  graphics  drawing  library  with  interface  Drawable  and 
classes  Circle  and  Icon  (Figure [i^.  Circle  implements  Drawable,  but  Icon  implements  no  inter¬ 
faces.  In  particular,  it  does  not  implement  Drawable,  since  it  does  not  support  setting  an  alpha 
transparency. 

Now,  suppose  we  wish  to  write  a  method  centerAndDraw  that  takes  an  object  that  supports 
the  setPosition  and  draw  methods,  and  draws  an  item  centered  on  the  canvas.  In  principle,  this 
method  should  be  applicable  to  either  an  Icon  or  a  Circle.  Unfortunately,  no  appropriate  type 
exists  that  would  allow  instances  of  either  Icon  or  Circle  to  be  passed  to  the  method.  The  pro¬ 
grammer’s  only  options  are  to  use  reflection  (which  is  not  statically  type-safe),  to  create  two 
identical  versions  of  centerAndDraw  (one  that  applies  to  Icon  and  one  that  applies  to  Drawable), 
or  to  use  Object  as  the  type  of  item  and  perform  instanceof  tests  (also  not  statically  type-safe). 


^Obviously,  there  is  a  continuum  of  “modularity,”  with  my  definition  of  “modular”  at  one  end,  and  whole- 
program  analysis  on  the  other.  Millstein  jMillstein  and  Chambers|[2002  Millstein|2oo3|  identifies  several 
interesting  points  in  this  design  space,  in  the  context  of  external  methods  and  multimethods. 
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interface  Drawable  { 
void  draw()j 

void  setPosition(int  Xj  int  y)j 
void  setAlpha(int  alpha); 

3 

class  Circle  implements  Drawable  { 
void  draw( )  {  . . .  3 

void  setPosition(int  Xj  int  y)  {  ...  3 
void  setAlpha(int  alpha)  {  ...  3 

3 

class  Icon  { 

void  draw( )  {  . . .  3 

void  setPosition(int  Xj  int  y)  {  ...  3 

3 

void  centerAndDraw( _  item)  {  // what  type  to  use  here? 

item. setPosition(xpoSj  ypos); 
item.drawO; 


Figure  i.i:  An  appropriate  type  does  not  exist  for  the  parameter  to  centerAndDraw. 


Of  course,  if  we  did  control  all  the  code  for  the  graphics  library,  there  would  be  a  simple 
solution:  we  would  simply  create  a  type  Bitmap  containing  the  two  methods  in  question,  and 
make  Drawable  extend  Bitmap  and  Circle  implement  Bitmap.  The  type  of  centerAndDraw’s  argu¬ 
ment  would  then  be  Bitmap.  Unfortunately,  in  our  scenario,  only  the  maintainer  of  the  graphics 
library  would  be  able  to  make  such  a  change. 

The  problem  here  is  that  Java  does  not  support  retroactive  interface  implementation,  where 
a  class  could  be  declared  as  implementing  an  interface  (or  an  interface  be  declared  as  extending 
another  interface)  after  the  point  at  which  the  class  or  interface  was  originally  defined.  This 
problem  is  not  confined  to  Java,  however — it  arises  in  any  nominally-typed  language  that  sup¬ 
ports  modular  typechecking. ^  Since  modular  typechecking  is  crucial  for  effective  software  de¬ 
velopment  (particularly  in  a  team  environment),  a  practical  solution  must  not  preclude  its  pos¬ 
sibility. 

In  my  empirical  studies  (Chapter]^,  I  found  that  the  aforementioned  situation  does  indeed 
arise  in  practice:  sometimes  an  appropriate  type  does  not  exist  and  programmers  resort  to  code 
duplication  and  instanceof  tests.  Not  only  does  this  cause  problems  when  a  change  must  be 


^Some  have  proposed  nominally-typed  languages  that  support  a  form  of  retroactive  abstraction,  but  these 
designs  are  either  awkward,  have  unusual  semantics,  or  require  non-modular  typechecking  |Wehr  et  ^ 


Ostermann  2oo8|.  These  designs  are  described  further  in  Sections  2.6  and 
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Figure  1.2:  Manually  composing  interfaces  using  nominal  subtyping 


made  to  all  of  the  code  copies,  the  solution  is  not  extensible;  if  a  new  type  is  later  added  that 
supports  the  required  interface,  programmers  must  add  new  code  to  handle  the  new  type. 

Composing  Interfaces 

There  is  another  limitation  of  nominal  sub  typing:  it  makes  it  difficult  to  compose  interfaces. 
Concretely,  suppose  that  in  our  graphics  library  we  have  three  interfaces:  Scalable,  Drawable, 
and  Rotatable  (Fig.  ED-  Now,  if  we  wish  to  describe  types  that  support  some  combination  of 
these  interfaces,  nominal  subtyping  would  require  us  to  create  4  new  interfaces.  Aside  from 
the  tedious  nature  of  this  design,  the  programmer  would  also  have  to  remember  to  use  these 
compound  interfaces  appropriately.  That  is,  if  we  have  the  declaration 

class  Glyph  implements  Scalable,  Drawable 

then  a  Glyph  could  not  be  passed  to  a  method  that  expected  a  ScalableDrawable  object,  since 
Scalable,  Drawable  is  not  equivalent  to  ScalableDrawable.  The  root  of  the  problem  is  that  there 
are  no  type  equalities  in  a  system  with  only  nominal  subtyping;  each  new  type  name  is  distinct 
from  all  other  types. 


It  would  be  possible  to  use  intersection  types  to  solve  this  particular  problem  jCoppo  and 

Dezani-Ciancaglini||i978|  Coppo  et  al.||i979 

Pottinger 

1980)  Biichi  and  Weck||i998);  program- 

mers  would  never  create  the  composition  interfaces  and  would  instead  write  code  in  terms  of 
e.g.  Scalable  a  Drawable.  However,  this  is  not  a  complete  solution;  without  explicit  support 
for  retroactive  abstraction,  programmers  must  still  anticipate  every  possible  “interesting”  inter¬ 
face.  In  other  words,  intersection  types  would  not  solve  the  problem  we  saw  above  with  the 
centerAndDraw  method. 

To  solve  both  the  problems  of  retroactive  abstraction  and  composing  interfaces,  I  propose 
using  structural  subtyping,  which  I  describe  in  detail  below. 

Adding  Methods  to  Existing  Classes 

Just  as  it  is  useful  to  add  new  types  to  an  existing  hierarchy,  it  can  also  be  useful  to  add  new  code 
that  operates  on  an  existing  hierarchy.  Unfortunately,  traditional  languages  make  it  difficult 
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static  void  readLine(Reader  r)  { 
if  (r  instanceof  BufferedReader) 

//  look  in  buffer  first 
else  if  (r  instanceof  StringReader) 
//search  string  directly 
else  if  (r  instance  of  InputStreamReader) 
//  read  an  array  of  bytes 

else 

//  call  readQ  in  a  loop 

] 


Figure  1.3:  Manual  dispatch  using  instanceof  tests 


either  to  retroactively  add  new  methods  to  existing  classes,  or  to  write  new  code  that  dispatches 
on  an  existing  class  hierarchy. 

Concretely,  suppose  we  wish  to  add  new  functionality  for  objects  of  type  Java. io. Reader.  This 
class  has  a  method  for  reading  a  byte  at  at  time,  but  we  would  like  to  create  a  method  that  reads 
an  entire  line  at  a  time. 

Depending  on  the  type  of  Reader  object  that  we  have,  this  readLine  method  would  be  im¬ 
plemented  differently.  A  BufferedReader,  for  instance,  can  implement  this  method  efficiently  by 
searching  for  a  newline  character  in  the  contents  of  the  buffer,  while  a  StringReader  can  perform 
an  even  more  efficient  operation.  For  other  types  of  readers,  we  may  perhaps  implement  this 
method  by  calling  read  ( ) ,  which  reads  one  byte  at  a  time. 

However,  since  Reader  is  part  of  the  Java  Standard  Library,  new  methods  cannot  be  added 
to  it.  Consequently,  the  only  way  to  write  new  code  that  dispatches  on  this  hierarchy  is  to  hand- 
code  dispatch  using  instanceof  tests,  as  in  Fig.  El  This  design  has  several  problems:  it  is  tedious 
and  error-prone  (for  example,  cases  for  subtypes  must  appear  before  cases  for  supertypes)  and 
it  is  not  extensible.  If  another  developer  later  adds  a  new  subclass  of  Reader,  a  new  case  must  be 
added  to  readLine — posing  problems  if  this  developer  cannot  modify  readLine. 

Of  course,  if  was  expected  that  programmers  would  want  to  add  new  methods  to  this  hier¬ 
archy,  the  designers  could  have  implemented  the  “Visitor”  design  pattern  [Gamma  et  al.  1994). 
However,  as  others  have  noted  [Clifton  et  al.||2006|  Millstein][2003|,  Visitor  introduces  its  own 
problems:  1)  its  need  must  be  anticipated  in  advance;  2)  adding  new  classes  to  the  hierarchy  be¬ 
comes  difficult;  3)  the  visitXXX  methods  must  all  have  the  same  return  type,  and  may  only  throw 
unchecked  exceptions  (or  only  some  particular  checked  exception);  4)  inheritance  among  the 
classes  to  be  visited  can  pose  design  issues.^ 


3  To  illustrate  the  last  problem,  suppose  we  have  a  visitor  defined  on  the  Reader  class  hierarchy.  With  the 
original  visitor  pattern  jGamma  et  aL[[i9^,  the  programmer  would  provide  methods  visitBufferedReader, 
visitStringReader,  etc.,  but  not  visitReader.  Unfortunately,  this  makes  it  impossible  to  put  common  function¬ 
ality  in  a  superclass  case;  each  of  the  visitXXX  methods  must  be  overridden  to  perhaps  call  the  same  helper 
method.  A  more  advanced  variant  of  Visitor  solves  this  problem  |  Vlissides|i999|,  but  some  frameworks  and 
libraries  still  use  the  original  pattern — even  modern  frameworks  such  as  the  Eclipse  JDT. 
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Figure  1.4:  A  stream  class  hierarchy  forming  an  inheritance  diamond 


To  solve  these  problems,  I  propose  using  external  methods  (described  further  below),  which 
have  been  extensively  studied  in  the  literature  (e.g.,  |Shalit|i997  Chambers|i992  Clifton  et  al. 
2008|). 


2000 


Allen  et  al. 


Reusing  Code  From  Multiple  Classes 

While  structural  subtyping  and  external  dispatch  are  useful  features,  they  do  not  provide  com¬ 
plete  support  for  the  kind  of  code  reuse  that  is  needed  in  practice  ||Ellis  and  Stroustru^|i990 


Bracha  and  Cook||i990  Flatt  et  aL]|i998  Ducasse  et  al.||2006| .  For  instance,  in  a  single  inheri¬ 


tance  setting,  there  is  no  satisfactory  solution  when  two  or  more  classes  need  to  share  features 
that  are  not  contained  in  their  (unique)  common  parent.  These  features  must  either  be  pushed 
into  the  common  parent  (where  it  does  not  semantically  belong)  or  they  must  be  duplicated  in 
the  classes  in  question  [Ducasse  et  al.||20o'6|. 


Consequently,  various  alternatives  to  single  inheritance  been  proposed,  such  as  multiple 


inheritance  |  Keene  and  Gerson 

1989 

Ellis  and  Stroustrup||i99ol 

Meyer||i992 

,  mixins  [Bracha 

and  Cook||i990 

Flatt  et  al.||i998 

Ancona  et  al.||2003|,  and  traits  | 

Scharli  et  al. 

2003I  [Smith  and 

Drossopoulou  2 

1005 

Flatt  et  al.|2006 

leppy  and  Turon  2007t|Bergel  et  al.52008).  Unfortunately, 

each  of  these  designs  has  its  own  drawbacks.  Multiple  inheritance  suffers  from  the  diamond 
problem  (described  below),  mixins  must  be  applied  linearly  and  may  not  inherit  from  one  an¬ 
other,  and  traits  may  not  contain  state. 

Diamond  inheritance  describes  the  situation  when  a  class  C  inherits  an  ancestor  A  through 
more  than  one  path  (e.g.,  InputOutputStream’s  relationship  to  Stream  in  Fig.|i.4|l.  This  is  par¬ 
ticularly  problematic  when  the  class  at  the  top  of  the  diamond  (e.g..  Stream)  has  fields — should 
classes  like  InputOutputStream  inherit  multiple  copies  of  the  fields  or  just  one?  Virtual  inheri¬ 


tance  in  C++  is  designed  as  one  solution  for  obtaining  the  latter  semantics  |  Ellis  and  Strous- 
trup  i99o|.  But  with  only  one  copy  of  Stream’s  fields,  object  initializers  are  a  problem:  if 
InputOutputStream  transitively  calls  Streams’s  constructor  or  initializer,  how  can  we  ensure  that 


it  is  called  only  once?  Existing  solutions  either  restrict  the  form  of  constructor  definitions  |  Oder- 
skylaooy)  or  ignore  some  constructor  calls  |  Ellis  and  Stroustrup||i99o|. 

There  is  another  consequence  of  the  diamond  problem:  it  causes  multiple  inheritance  to 
interact  poorly  with  modular  typechecking  of  external  and  multiple  dispatch — my  proposed 
solution  to  the  problem  of  the  previous  subsection.  In  particular,  in  the  presence  of  multiple 
inheritance,  ambiguous  external  method  definitions  are  difficult  to  detect  in  a  modular  manner. 


1.3-  Unity 
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To  illustrate  this  problem,  suppose  we  have  the  inheritance  diamond  of  Fig.  1.4  Now,  if  we 


define  external  method  m  on  both  InputStream  and  OutputStream,  there  would  be  an  ambiguity 
if  m  were  called  on  an  object  of  type  InputOutputStream,  as  neither  definition  of  m  is  more 
specific  than  the  other.  Detecting  this  situation  would  require  either  searching  for  subclasses 
of  InputStream  and  OutputStream  when  m  is  defined  (a  non-modular  check),  or  searching  for 
external  method  definitions  like  m  when  InputOutputStream  is  defined  (also  non-modular). 

Interestingly,  this  problem  arises  even  with  restricted  forms  of  multiple  inheritance,  such  as 
traits  or  Java  multiple  interface  inheritance.  Previous  work  either  disallows  multiple  inheritance 
across  module  boundaries  jMillstein  and  Chambers||2002|,  or  burdens  programmers  by  requir¬ 


ing  that  they  always  provide  (possibly  numerous)  disambiguating  methods  |  Frost  and  Millstein 
20o6|  [Allen  et  al.|2007|. 


1.3  Unity 

I  propose  a  new  language.  Unity,  to  solve  the  aforementioned  problems.  In  this  section  I  describe 
Unity  at  a  high  level  and  give  an  overview  of  how  it  can,  in  fact,  solve  these  problems.  Unity  has 
three  key  features:  structural  subtyping,  external  dispatch,  and  multiple  inheritance. 


Structural  Subtyping 


Structural  subtyping  provides  a  solution  to  both  the  problem  of  retroactive  abstraction  and  that 
of  composing  types.  Structural  subtyping  is 
been  extensively  studied  in  a  formal  setting 

|.  In  a  language  with  nominal  subtyping  (such  as  all 
mainstream  statically-typed  object-oriented  languages),  a  type  1/  is  a  subtype  of  T  if  and  only 
if  it  is  declared  to  be.  In  a  language  with  structural  subtyping,  on  the  other  hand,  a  type  U  is 
a  subtype  of  T  if  its  methods  and  fields  are  a  superset  of  T’s  methods  and  fields  (possibly  with 
refined  types).  The  interface  of  a  class  is  simply  its  public  fields  and  methods;  there  is  no  need 
to  declare  a  separate  interface  type. 

Structural  subtyping  offers  a  number  of  benefits,  including  the  ability  to  create  retroactive 
abstractions — new  types  that  have  a  supertype  relationship  to  existing  types.  In  our  example 
above,  we  would  simply  create  a  structural  type  Bitmap  (with  the  setPosition  and  draw  methods) 
and  it  would  automatically  be  a  supertype  of  both  Drawable  and  Circle,  without  having  to  modify 
those  types.  This  is  illustrated  in  Fig.  S  In  Unity,  a  brand'^  is  similar  to  a  class  in  Java-like 
languages.  The  type  Bitmap  is  now  used  as  the  argument  to  centerAndDraw,  with  the  result  that 
either  a  Circle  or  an  Icon  may  be  passed  to  it. 

This  design  also  has  benefits  for  code  evolution:  if  a  new  method  m  with  type  t  is 
added  to  both  Drawable  and  Circle,  they  are  each  subtypes  of  the  structural  type  {m  :  t}  (and 
also  Bitmap  a  {m :  tJ).  Finally,  structural  subtyping  makes  it  trivial  to  compose  types — the 
type  Bitmap  is  automatically  equivalent  to  the  combination  of  the  types  { setPosition  ( )  }  and 
{ draw() }. 


1999I  Leroy  et  al.  2004)  Malayeri  2009a 


very  popular  in  the  research  community,  and  has 


Cardelli|i988|  [Bruce  et  al.||2003[  Fisher  and  Reppy 


■^The  name  “brand”  is  borrowed  from  Strongtalk  jBracha  and  Griswold  1993),  which  in  turn  borrowed  it 


from  Modula-3  |Nelson 


1991 
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type  Drawable  =  Object  (  let  centerAndDraw  =  fn  item  :  Bitmap  --> 

draw :  unit  ^  unit, 

setPosition  :  int  *  int  ^  unit,  item.setPosition(xpos,  ypos) ; 

setAlpha  :  int  ^  unit  item.draw() 

) 

brand  Circle  extends  Object  ( 
method  draw( )  :  unit  =  .  .  . 

method  setPosition(x :  int,  y :  int)  :  unit  =  .  . .  centerAndDraw  circle  // typechecks 
method  setAlpha(alpha  :  int)  :  unit  =  .  . .  centerAndDraw  icon  //typechecks 

) 


brand  Icon  extends  Object  ( 
method  draw( )  :  unit  =  .  .  . 
method  setPosition (x :  int,  y :  int)  :  unit  =  .  . . 

) 

type  Bitmap  =  Object  ( 
draw :  unit^  unit, 
setPosition  :  int  *  int  ^  unit, 

) 


Figure  1.5:  Re-writing  Fig.|i.i|using  Unity’s  structural  types.  A  brand  declaration  is  similar  to 
a  class  declaration  in  Java. 


However,  nominal  subtyping  has  advantages  as  well,  and  a  language  that  provides  only  struc¬ 
tural  subtyping  would  forgo  these  benefits  |Pierce||20^  Ostermann||20o8|[Malayeri  and  Aldrich 
2008a  I .  First,  nominal  subtyping  allows  the  programmer  to  express  and  enforce  design  intent 
explicitly.  A  programmer’s  defined  subtyping  hierarchy  serves  as  checked  documentation  that 
specifies  how  the  various  parts  of  a  program  are  intended  to  work  together.  As  a  consequence, 
explicit  specification  has  the  advantage  of  preventing  “accidental”  subtyping  relationships,  such 
as  the  standard  example  of  Cowboy.  draw()  and  Circle. draw()  |Magnusson|i99i|.  Nominal  sub¬ 
typing  also  allows  recursive  types  to  be  easily  and  transparently  defined,  since  recursion  can 
simply  go  through  the  declared  names.  Third,  error  messages  are  usually  much  more  compre¬ 
hensible,  since,  for  the  most  part,  every  type  in  a  type  error  is  one  that  the  programmer  has 
defined  explicitly.  Finally,  as  mentioned  by  Ostermann,  nominal  subtyping  has  a  useful  default 
of  assigning  blame  to  the  definition  of  a  type  when  a  subtype  relation  does  not  hold.  In  contrast, 
structural  subtyping  defers  blame  to  the  point  at  subsumption  is  applied. 

For  these  reasons,  as  well  as  to  support  external  methods — which  allow  programmers  to 
retroactively  add  new  methods  to  existing  classes — Unity  provides  both  nominal  and  structural 
subtyping. 5  In  the  proposed  design,  a  type  has  both  a  nominal  and  a  structural  component,  and 
subtyping  takes  both  components  into  account. 


®See  Sect.  2.2.3  for  an  explanation  of  why  some  form  of  nominal  subtyping  is  extremely  advantageous  for 


supporting  external  dispatch. 
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string  BufferedReader .  readLineO  {  }  // look  in  buffer  first 

String  StringReader. readLineO  {  •••  3  // search  string  directly 

String  InputStreamReader .  readLine( )  {  ...  ]  // read  an  array  of  by  tes 

String  Reader. readLineO  {  •••  3  // call  readQ  in  a  loop 


Reader  f  =  new  FileReader("bar.txt") j 
String  s  =  f.readLineOj  // typechecks 


Figure  i.6:  Re-writing  instanceof  tests  (Fig.  1.3  i  using  Multijava  external 


mernoGS 


External  Dispatch 


External  methods  are  like  ordinary  methods,  but  they  can  be  added  in  a  different  module  than 
the  classes  on  which  they  perform  dispatch.^  External  dispatch  can  make  code  more  flexible 
and  easier-to-evolve  because  the  language  no  longer  requires  that  the  set  of  methods  of  a  class 
be  fixed  when  it  is  defined.  External  dispatch  (and  multimethod  dispatch,  a  related  feature) 
is  supported  by  a  number  of  languages,  such  as  CEOS,  Dylan,  Cecil,  Multijava,  and  Eortress 
|Paepcke|i993|  ^alit|i997  Chambers||i992| [Clifton  et  al.|20oo|  Allen  et  al.|20o8 1. 

External  methods  solve  the  problem  of  adding  new  code  that  dispatches  on  an  existing  hi¬ 
erarchy.  Eor  instance,  to  add  a  new  method  to  the  Reader  class,  we  simply  write  an  external 
method  readLine  in  a  new  module.  Eigure [1^ shows  such  an  external  method  written  in  Multi- 
Java  [Clifton  et  al.  2000].  This  new  method  can  be  called  just  like  an  ordinary  method;  readLine 
can  be  called  on  any  subclass  of  Reader,  once  the  external  method  has  been  defined. 


Unfortunately,  while  the  new  external  method  allows  readLine  to  be  called  on  Reader,  it  does 
not  change  the  interfaces  that  Reader  implements.  Eig.  ji.yj  shows  a  Multijava  example  where 
we  would  like  to  pass  an  object  of  type  Reader  to  the  method  findString,  which  expects  a  first 
argument  of  type  Readable.  Even  though  we  have  added  a  new  method  to  Reader  to  make  it 
conform  to  Readable,  without  retroactive  abstraction,  the  last  line  does  not  typecheck.  Thus, 
the  need  for  retroactive  abstraction  is  even  more  apparent  when  new  methods  can  be  added  to 
existing  classes. 


fortunately.  Unity  provides  a  solution  to  this  problem  by  including  both  structural  subtyping 
and  external  dispatch,  while  retaining  the  modular  typechecking  of  Multijava.  We  could  rewrite 
this  example  in  Unity  as  in  Eig.ji.Sj 

Here,  the  function  findString  takes  as  its  first  argument  any  object  that  has  a  readLine  method 
that  has  only  the  receiver  as  an  argument  and  that  returns  a  string  (i.e,  type  “()  ^  string”).  Once 
the  external  method  readLine  has  been  defined  on  Reader,  all  subtypes  of  Reader  conform  to  this 
Structural  type  and  the  last  line  typechecks. 


®This  document  uses  a  very  minimal  definition  of  “module”:  a  module  is  simply  a  set  of  definitions.  The 
interface  of  the  module  is  the  types  of  those  definitions. 
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interface  Readable  {  String  readLine()j  ] 
boolean  findString(Readable  r.  String  s)  {  ...  ] 

// find  string  s  in  stream  r 

String  Reader .  readLine( )  {  ...  ]  // new  external  method 

f  =  new  FileReader("bar.txt"); 
findString(f,  foo);  //fails  to  typecheck! 


Figure  1.7:  External  methods  in  Multijava  highlight  the  need  for  retroactive  abstraction.  The 
last  line  does  not  typecheck  because  Reader  does  not  implement  Readable,  even  though  it  has 
a  readLine  method. 


//takes  any  object  with  a  readLine  method 

let  findString  =  fn  (r :  Object  (readLine :  ()  -^  string)  ,  s  :  string)  -->... 

//external  method  definitions 

method  Reader. readLine  :  ( )  ^  string  =  .  .  .  //external  method  defined  on  ‘Reader’ 
method  BufferedReader. readLine  :  ( )  ^  string  =  .  .  . 
method  StringReader. readLine :  ( )  =>  string  =  .  . . 


using  readLine  in 

letf  =  new  FileReader("bar.txt")  in 
findString  (f,  "foo")  // typechecks! 


Figure  1.8:  Rewriting  the  code  of  Fig.  1.7  in  Unity 


Multiple  Inheritance 


As  previously  described,  the  root  of  the  difficulty  with  multiple  inheritance  is  the  potential 
for  inheritance  diamonds;  other  issues  with  multiple  inheritance  (such  as  inheriting  features 
with  duplicate  names)  have  been  effectively  solved  by  previous  languages  ||Meyer|i992|  Ellis  and 
Stroustrup||i99o|. 

Following  this  observation.  Unity  takes  a  novel  approach:  while  permitting  multiple  inheri¬ 
tance,  it  disallows  inheritance  diamonds  entirely.  So  that  there  is  no  loss  of  expressiveness,  the 
notion  of  inheritance  is  divided  into  two  concepts:  an  inheritance  dependency  (expressed  using 
a  requires  clause,  an  extension  of  a  Scala  construct  [Odersky  and  Zenger  2005)  Odersky|2007|) 
and  ordinary  inheritance.  Chapterjsjillustrates  how  programs  that  require  diamond  inheritance 
can  be  translated  to  a  hierarchy  that  uses  a  combination  of  requires  and  multiple  inheritance, 
without  the  presence  of  diamonds.  As  a  result.  Unity  retains  the  expressiveness  of  diamond 
inheritance  while  avoiding  its  problems. 


1.4-  Statement  of  the  Thesis 
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vides  subtyping  without  inheritance. 


To  provide  a  sense  of  this  translation,  Fig.|i.9|shows  how  the  inheritance  diamond  of  Fig. 


1.4 


is  translated  to  Unity.  Essentially,  inheritance  diamonds  are  converted  to  subtyping  diamonds — 
which  are  allowed  by  the  language — using  the  requires  construct.  The  details  of  the  multiple 
inheritance  design,  as  well  as  a  discussion  of  the  revised  stream  hierarchy,  are  described  in  Chap¬ 
ter  [3] 


1.4  Statement  of  the  Thesis 

The  thesis  of  this  dissertation  is: 

An  object-oriented  programming  language  can  provide  integrated  support  for  (a) 
external  dispatch,  (b)  nominal  subtyping  (c)  structural  subtyping  and  (d)  multiple 
inheritance — all  without  sacrificing  modular  typechecking  These  richer  structuring 
mechanisms  can  serve  to  make  code  more  reusable  and  adaptable. 


The  thesis  is  affirmed  through  several  hypothesis;  each  is  described  below  along  with  a  descrip¬ 
tion  of  its  supporting  evidence. 

Hypothesis  I 

A  language  with  synergy  between  structural  subtyping  and  external  dispatch  can  be  achieved 
through  a  novel  combination  of  structural  and  nominal  subtyping. 

Validation: 

•  Unity  language  design  and  type  system  (Sectionja^. 

•  Type  safety  proof  for  the  core  language  (Section[3.7.4|and  Appendix [A). 

Hypothesis  II 

By  providing  retroactive  abstraction,  structural  subtyping  can  be  used  to  improve  the  reusability 
and  maintainability  of  existing  object-oriented  programs. 
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Validation: 

•  Quantitative  and  qualitative  analyses  of  open-source  Java  programs  chosen  from  a  variety 
of  domains  (Chapter  [^: 

1.  Evidence  suggesting  that  structural  subtyping  could  help  make  method  parameters 
more  general  (Sect. [4^. 

2.  High  frequency  of  common  methods — methods  with  the  same  name  and  signa¬ 
ture,  but  that  are  not  contained  in  a  common  supertype  of  the  enclosing  classes 

(Sectlq.S.i). 

3.  Low  frequency  of  common  methods  that  represent  an  accidental  name  clash 
(Sect  [4^5^. 


4.  Evidence  that  some  cases  of  code  duplication  could  be  avoided  with  structural  sub¬ 
typing  (Sect.l4.5-3)- 


Hypothesis  III 

Existing  language  designs  can  lead  to  coding  patterns  that  defer  errors  to  runtime;  structural 
subtyping  could  provide  more  static  typechecking  in  these  situations  by  allowing  programmers 
to  encode  more  properties  directly  in  the  type  system. 

Validation: 

•  Quantitative  and  qualitative  data  showing  that: 

1.  Some  Java  runtime  exceptions  (i.e.,  OperationUnsupportedException)  can 
be  eliminated  in  a  straightforward  manner  with  a  design  that  uses  struc¬ 
tural  subtyping  (Sect.  [4^. 

2.  Some  uses  of  Java  reflection  can  be  converted  to  uses  of  structural  sub¬ 
typing  (Sect.  [4^. 


Hypothesis  IV 

The  combination  of  structural  subtyping  and  external  dispatch  has  the  synergistic  effect  of  pro¬ 
viding  an  expressive  form  of  retroactive  abstraction. 

Validation: 

•  Examples  illustrating  the  increase  in  expressiveness  when  these  features  are 
combined  (Sect. [2!^. 

•  Results  from  empirical  study  showing  that  many  cases  of  cascading  instanceof 
tests  in  Java  programs  may  be  re-written  using  a  combination  of  structural 
subtyping  and  external  methods  (Sect. [4^,  thereby  allowing  an  existing  class 
to  be  adapted  to  a  new  context. 


Hypothesis  V 

Through  the  use  of  a  novel  multiple  inheritance  scheme,  modular  typechecking  can  be  per¬ 
formed  in  a  language  with  multiple  inheritance  and  external  dispatch,  without  requiring 
programmer-specified  disambiguating  methods. 


1.4-  Statement  of  the  Thesis 
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Validation: 


Type  safety  proof  for  the  core  language  (Section  3.7.4|and  Appendix [A|. 
Detailed  argument  describing  modularity  of  Unity  type  system  (Section[3.7.3|. 


Hypothesis  VI 

A  language  can  be  designed  with  a  new  form  of  multiple  inheritance — multiple  inheritance  with¬ 
out  diamonds — a  design  that  provides  more  opportunities  for  code  reuse  and  that  is  more  ex¬ 
pressive  than  other  proposed  alternatives  to  full  multiple  inheritance  (i.e.,  multiple  interface 
inheritance,  mixins,  and  traits). 

Validation: 

•  Unity  multiple  inheritance  design  (Chapter  [3]). 

•  Detailed  comparison  to  the  existing  proposals  in  the  context  of  an  example  in 
Unity  (Sect.j^s)- 

Hypothesis  VII 

By  converting  inheritance  diamonds  to  inheritance  dependencies  and  subtyping  among  abstract 
classes  (via  a  requires  clause),  a  program  with  inheritance  diamonds  can  be  systematically  trans¬ 
lated  into  a  program  with  multiple  inheritance  but  without  any  inheritance  diamonds. 

Validation: 

•  Real-world  examples  showing  how  C++  inheritance  diamonds  can  be  system¬ 
atically  translated  to  Unity  (Section[3^. 


Conventions 

This  document  makes  use  of  the  following  typographical  conventions: 

•  monospace  is  used  for  Java  code  listings 

•  (proportional-width)  sans  serifs  is  used  for  Unity  code  listings,  all  inline  code  references, 
and  (in  the  formal  system)  keywords 

•  utopia  italic  is  used  for  metavariables  (e.g.,  B,  C,  D)  and  auxiliary  functions  (e.g.,  mtype) 

•  Small  Caps  is  used  to  name  inference  rules 

•  boldface  is  used  to  name  judgements  (e.g.,  p  ok) 


^It  is  more  visually  pleasing  than  monospace. 
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Chapter  2 

Structural  Subtyping  and  External 
Dispatch 


“Must  a  name  mean  something?”  Alice  asked  doubtfully. 

“Of  course  it  must,”  Humpty  Dumpty  said  with  a  short  laugh: 

“my  name  means  the  shape  I  am — and  a  good  handsome  shape  it  is, 
too.  With  a  name  like  yours,  you  might  be  any  shape,  almost.” 

Lewis  Carroll  {Through  the  Looking-Glass) 

If  it  looks  like  a  duck,  and  quacks  like  a  duck,  we  have  at  least  to 
consider  the  possibility  that  we  have  a  small  aquatic  bird  of  the  family 
Anatidae  on  our  hands. 

Douglas  Adams  {Dirk  Gently’s  Holistic  Detective  Agency) 


This  chapter  describes  one  of  the  main  contributions  of  Unity:  the  combination  of  structural 
subtyping  and  external  dispatch.^  A  clean  integration  of  these  features  is  achieved  using  a  com¬ 
bination  of  nominal  and  structural  subtyping.  The  chapter  introduces  Unity  through  a  series  of 
examples,  describes  practical  applications  of  the  work  (design  patterns  and  optional  methods), 
and  presents  the  full  formalization  of  the  Unity  calculus.  The  multiple  inheritance  aspects  of 
the  calculus  are  visually  indicated  and  will  be  described  in  Chapter  [3] 


2.1  Overview  of  Unity 


In  Unity,  an  object  type  is  a  value  (usually  a  record)  tagged  with  a  brand.  Brands  induce  the 
nominal  subtyping  relation,  which  I  call  “sub-branding.”  Brands  are  nominal  in  that  the  user 
defines  the  sub-brand  relationship,  like  the  subclass  relation  in  languages  like  Java,  Eiffel,  and 
C++. 


^The  main  contributions  of  this  chapter  appeared  in  previous  publications  (Malayeri  and  Aldrich 


2007 


20o8al. 
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The  structural  subtyping  component  of  the  system  is  used  for  subtyping  the  set  of  methods 
of  a  brand  (denoted  by  {m, :  t;  The  usual  structural  depth  and  width  subtyping  rules  apply 

to  this  method  set.  If  B  has  methods  m  :  r  and  n  ■  a,  then  an  object  0  with  brand  B  conforms 
to  the  types  B[m  :r,n:  a),  B[m  :  t),  BQ,  and  B[n  :  a'}  (where  a  is  a  subtype  of  a').^  Also,  since 
Object  is  the  root  of  the  inheritance  hierarchy,  the  object  0  also  has  type  Object(m :  t,  n  :  a).  This 
last  relation  is  achieved  through  the  combination  of  nominal  and  structural  subtyping. 

In  particular,  the  system  has  the  following  rule  for  general  subtyping  (denoted  by 


Definition  2.1  (General  subtyping). 

B(mi :  Ti  <  C(nj  :  Oj  Ai  -^)  if  and  only  if: 

•  B  is  a  sub-brand  of  C,  and 

•  {nii :  Ti  is  a  structural  subtype  of  {Uj  :  Uy  AI-.j;} 


In  turn,  structural  subtyping  obeys  the  following  rule: 


Definition  2.2  (Structural  subtyping). 

{mi :  Ti  is  a  structural  subtype  of  [rij  :  aj  if  and  only  if: 

•  [rij  c  [mi  and 

•  mi  -  rij  implies  t/  <  a j 


In  other  words,  the  set  of  labels  in  the  second  structural  type  N  must  be  a  subset  of  the  set  of 
labels  in  the  first  type  M,  and  for  identical  labels  m,  and  rij,  the  corresponding  types  must  be  in 
the  (general)  subtype  relation. 

Unity  has  two  kinds  of  method  declarations:  internal  and  external.^  Internal  methods  are 
defined  within  a  brand  declaration,  similar  to  methods  in  Java-like 
in  Unity  are  similar  to  those  in  Multijava  and  related  languages 
2003);  they  may  be  defined  outside  of  a  brand  but  perform  dispatch  and  may  be  overridden."^ 

To  support  information  hiding,  Multijava  does  not  permit  an  external  method  defined  on 
class  C  to  access  C’s  private  members.  Similarly,  in  Unity,  external  methods  may  not  access 
any  of  the  corresponding  brand’s  fields.  Sub-brands,  however,  may  access  super-brand  fields,  so 
fields  in  Unity  are  like  C++  “protected”  members. 

^This  is  not  strictly  the  case  in  the  formal  system,  which  distinguishes  between  simple  and  qualified 
method  names.  Essentially,  qualified  method  names  are  not  included  an  object’s  structural  type,  but  may  be 
called  using  nominal  method  lookup.  Structural  method  names  are  added  to  an  object  explicitly  using  map¬ 
ping  expression  (which  would  not  appear  in  the  surface  syntax).  However,  the  examples  that  follow  assume 
that  all  of  the  methods  of  a  brand  appear  in  the  structural  type  of  its  objects  and  do  not  make  a  distinction 
between  simple  and  qualified  method  names. 

^To  simplify  the  discussion,  the  remainder  of  this  document  abbreviates  “internal  method  declaration”  as 
“internal  method,”  and  analogously  for  “external  method  declaration.” 

'’^This  is  in  contrast  to  “extension  methods”  in  C#  3.0,  which  are  merely  syntactic  sugar  for  static  methods 
defined  in  a  helper  class. 


languages.  External  methods 
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Note  that  external  methods  are  closely  related  to  multimethods,  which  are  methods  that  may 
dispatch  on  any  subset  of  their  arguments — not  just  the  receiver.  The  formal  system  does  not 
include  multimethods  however,  as  there  is  a  straightforward  modular  encoding  of  asymmetric 
multimethods  using  external  methods.®  Consequently,  the  same  typechecking  issues  apply  to 
both  external  methods  and  asymmetric  multimethods.® 


2.2  Unity  by  Example 

The  section  presents,  by  example,  the  intuition  behind  Unity  and  situations  in  which  it  can  be 
useful.  The  examples  also  demonstrate  the  synergy  between  structural  subtyping  and  external 
methods.  I  also  provide  a  detailed  comparison  of  Unity  to  other  related  designs,  in  the  context 
of  the  examples. 


2.2.1  Example  1:  Streams 

The  first  example  involves  the  use  and  implementation  of  character-based  input  and  output 
streams. 


Defining  a  type.  For  input  streams,  we  first  wish  to  create  a  “Reader”  abstraction,  which  rep¬ 
resents  any  object  that  has  read,  skip,  and  close  methods  (with  appropriate  types). 

To  define  this  abstraction,  we  use  a  type  declaration  (Fig.  ED'  which  defines  a  type  abbrevi¬ 
ation.  The  nominal  component  (i.e.,  the  brand)  of  Reader  is  Object  and  its  structural  component 
consists  of  the  methods  read,  skip  and  close,  along  with  their  types. 

As  in  Java-like  languages,  the  brand  Object  is  the  root  of  the  inheritance  hierarchy;  all  brands 
directly  or  indirectly  extend  Object.  Note  that  the  code  listings  omit  the  extends  clause  for  direct 
sub-brands  of  Object  (e.g.,  AbstractReader). 

Reader  contains  two  different  arrow  types,  and  The  first,  is  used  for  method 
types.  To  the  left  of  this  arrow  is  the  receiver’s  structural  type.  The  nominal  component  is 
omitted — it  can  always  be  inferred  from  context  in  which  the  method  type  appears.  For  example. 
Object  is  the  nominal  component  of  the  method  read  in  the  type  abbreviation  Reader. 

To  simplify  the  formal  system,  methods  take  only  one  argument:  the  receiver  (i.e.,  this). 
If  additional  arguments  are  needed,  ordinary  first-class  functions  are  used;  these  have  types 
containing  the  arrow.  Functions  are  defined  using  the  “fn  x:  t  — >  e”  syntax. 

For  example,  skip  has  type  “( )  long  ^  long.”  Since  the  receiver’s  structural  type  is  empty, 
this  specifies  that  skip  can  be  applied  to  any  object  with  the  appropriate  (implicit)  nominal  type 


®With  asymmetric  multimethods,  the  order  of  arguments  affects  dispatch,  in  contrast  to  symmetric  dis¬ 
patch.  An  asymmetric  multimethod  dispatching  on  brands  can  be  translated  to  external  methods 

defined  on  each  Bt,  where  each  method  calls  the  method  in  brand  B,+i,  with  the  actual  code  defined  in  the 
method  on 

®Multimethods  with  symmetric  dispatch  semantics  introduce  a  few  orthogonal  typechecking  issues;  see 
iMillstein  and  Chambers|2002  Clifton  et  al.|2oo6  Millstein  et  al.|2o^  |Millstein|2oo3|  for  a  more  detailed 
discussion. 
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type  Reader  =  Object  (read:  ( )  =►  char, 
skip:  ( )  long  ^  long, 

close:  ( )  ^  unit)  //all  methods  take  reciever  of  type  Object( ) 

brand  AbstractReader  (...)  //default  implementation  for  methods  in  Reader 

brand  CharArrayReader  extends  AbstractReader  ( 
array:  char[];  //field 

method  read  =  .  . . ;  method  skip  =  method  close  =  . .  .  //same  types  as  in  Reader 

method  mark:  ( )  =>  unit  =  . .  .  //save  current  position 

method  reset:  ( )  =>  unit  =  .  .  .  //reset  to  position  saved  by  ‘mark’ 

method  seek:  ( )  long  ^  long  =  (  fn  pos:  long  -->...)  //seek  to  ‘pos’ 

) 

brand  BufferedReader  extends  AbstractReader  ( 

method  read  =  .  . . ;  method  skip  =  .  .  .  j  method  close  =  . .  .  //same  types  as  in  Reader 
method  mark:  ( )  ^  unit  =  . .  . 
method  reset:  ( )  =>  unit  =  .  .  . 

) 

//does  not  extend  AbstractReader 

brand  SomeOtherReader  (...)  //implementation  of  all  of  the  Reader  methods 

//  define  function  that  finds  string  ‘s’  in  the  ‘r’  stream 

let  findString  =  fn  (r:  Reader)  (s:  string)  :  long  -->... 

//all  typecheck;  each  is  a  subtype  o/Reader 
findString  bufReader  "foo" 
findString  CharArrayReader  "bar" 
findString  someOtherReader  "baz" 


Figure  2.1:  Stream  example  illustrating  brand  extension  and  structural  types 


(here,  Object).  Since  skip  needs  a  additional  argument  (the  number  of  bytes  to  skip),  its  return 
type  is  a  function  that  takes  a  long  and  returns  a  long. 

In  essence,  the  nominal  type  of  the  receiver  is  not  specified  in  method  types,  as  a  method 
type  always  appears  with  a  surrounding  brand.  Therefore,  in  the  type  :()=:>  t),  m’s  receiver 
has  type  B{)  (i.e.,  B  with  no  additional  structural  constraints).^ 


^It  would  be  possible  to  include  the  receiver  in  method  types,  but  then  the  formal  system  would  then  have 
to  ensure  consistency  between  receiver  types  and  their  enclosing  brand  type.  This  would  serve  only  to  add 
unnecessary  complexity. 
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//external  methods:  add  methods  to  AbstractReader  and  CharArrayReader, 

//  with  (static)  structural  constraint  that  receiver  must  have  ‘mark’  and  ‘reset’  methods 

method  AbstractReader. parse:  (  mark:  ( )  unit,  reset:  ( )  =>  unit  )  ^  unit  = 

//  ‘this’  has  type  AbstractReader(mark: . . reset: . . .) 

®  ...  // parse  text  using  ‘mark’  and  ‘reset’ 

method  CharArrayReader. parse:  ( )  ^  unit  = 

®  ...  //  more  ejficient parsing  using  method  ‘seek’ 


Figure  2.2:  Defining  an  external  method  (with  structural  constraints)  on  AbstractReader  and 
CharArrayReader 


Defining  brands.  In  Fig.  I  have  also  defined  a  “reader”  brand,  AbstractReader,  which 
contains  default  implementations  of  the  Reader  methods.  The  brands  CharArrayReader  and 
BufferedReader  each  extend  AbstractReader  and  provide  additional  functionality.  We  may  also 
define  reader  brands  that  do  not  extend  AbstractReader  but  still  conform  to  the  Reader  type;  the 
brand  SomeOtherReader  is  an  example. 

Now,  if  we  write  a  function  findString  that  operates  on  objects  of  type  Reader,  it  may  be  used 
on  any  of  the  brands  we  have  defined,  as  they  all  conform  to  the  Reader  type.  This  is  illustrated 
by  the  last  three  lines  of  the  code  listing. 


External  methods.  Thus  far,  we  have  used  only  internal  methods  and  ordinary  functions. 
Since  Unity  also  provides  external  methods,  we  can  define  new  functionality  in  a  new  module. 
That  is,  methods  do  not  need  to  appear  in  the  same  module  as  that  of  the  brands  on  which  they 
operate;  Fig.  2.2  contains  such  a  definition.  Here,  I  have  defined  an  external  method  parse  with 
two  implementations — for  each  of  AbstractReader  and  CharArrayReader.  This  second  override 
could  perhaps  perform  more  efficient  parsing  using  the  seek  method  in  CharArrayReader. 

The  external  method  defined  on  AbstractReader  also  defines  an  additional  structural  con¬ 
straint  on  the  receiver:  it  must  contain  the  mark  and  reset  methods,  in  addition  to  having 
brand  AbstractReader.  Consequently,  parse  may  only  be  called  on  objects  that  conform  to  the 
type  AbstractReader(mark:  ...,  reset: ...  ).  Note  that  the  structural  constraint  is  not  needed  for 
CharArrayReader,  since  all  objects  of  this  type  already  have  methods  mark  and  reset. 

Internal  methods  may  also  specify  structural  constraints;  Sect.  2.2.3  below  describes  how 
this  can  be  used  to  encode  Java-style  abstract  methods. 

Note  that  the  structural  constraint  is  purely  a  static  concept;  there  is  no  structural  method 
dispatch  (described  further  in  Sect.  2.2.3  k  That  is,  parse  may  only  be  called  by  objects  that  are 
statically  known  to  contain  mark  and  reset  methods.  Consequently,  it  is  a  type  error  to  define 
two  methods  that  differ  only  in  their  structural  constraints. 

External  methods  can  be  overridden  by  internal  methods  in  sub-brands.  For  example,  sup¬ 
pose  we  wish  to  define  a  type  of  reader  that  natively  supports  parse  functionality.  This  is  cap- 
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brand  ParseableReader  extends  BufferedReader  ( 

.  .  .  //implements  all  BufferedReader  methods 


2.2 


//overrides  external  method  parse  in  Fig. 

method  parse:  ( )  =>  unit  =  ®  .  .  .  //specialized  parse  algorithm  for  this  type  of  stream 


brand  SimpleReader  extends  AbstractReader(.  .  .  )  //contains  only  AbstractReader  methods 


using  parse  in 

bufReader. parse  //  typechecks;  BufferedReader  has  methods  ‘mark’ and  ‘reset’,  calls  code  (A) 
charArrayReader. parse  //typechecks.  calls  code  (B) 

simpleReader.parse  //doesn’t  typecheck:  need  methods  ‘mark’ and  ‘reset’ 
parseableReader. parse  //calls  code  (C)  above 

let  absReader:  AbstractReader(parse:  ()  ^unit)  =  parseableReader  in 
absReader. parse  //typechecks,  calls  code  (C)  above 

//doesn’t  need  to  be  in  using  block,  has  its  own  implementation 
parseableReader. parse  //calls  code  (C)  above 


Figure  2.3:  Overriding  and  using  the  external  method  parse 


tured  by  the  brand  ParseableReader  in  Fig.  |2.3|  Assuming  the  external  method  definition  of 
Fig.|2.2|is  in  scope,  ParseableReader  may  provide  its  own  version  of  parse. 

However,  to  call  the  external  method,  it  must  be  imported  into  a  lexical  scope  via  the 
using  expression,  as  illustrated  at  the  end  of  the  code  listing.  An  external  method  behaves 
just  as  an  ordinary  method;  dynamic  dispatch  occurs  for  the  expressions  “bufReader. parse”  and 
“charArrayReader. parse.”  However,  since  SimpleReader  does  not  contain  the  mark  and  reset  meth¬ 
ods,  the  expression  “simpleReader.parse”  does  not  typecheck.  (Below,  we  will  see  how  external 
methods  can  be  used  to  make  a  brand  conform  to  a  particular  structural  constraint.)  Note  that 
parse  may  be  called  on  any  ParseableReader  object  without  it  being  in  the  using  block,  as  the 
override  of  AbstractReader. parse  implicitly  imports  the  method  definition  for  objects  of  type 
ParseableReader. 


Adding  “write”  functionality.  Next,  we  add  code  for  writing  to  a  character  stream.  The 
type  Writer  represents  an  object  that  supports  basic  write  functionality;  AbstractWriter  provides 
default  implementations  for  these  methods  (Fig. [2^.  We  define  the  brand  StringStream,  which 
allows  both  reading  and  writing.  Note  however,  without  multiple  inheritance  (which  will  be 
introduced  in  Chapter[3]l,  StringStream  may  only  extend  one  of  AbstractWriter  and  AbstractReader 
(this  second  type  is  commented  out  in  the  extends  clause). 


2.2.  Unity  by  Example 
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type  Writer  =  Object  (append:  ( )  ^  char  Writer, 
write:  ( )  ^  int  ^  unit, 
flush:  ( )  ^  unit, 
close:  ( )  =>  unit) 

brand  AbstractWriter  (...)  //  default  implementation  o/Writer  methods 

brand  StringStream  extends  AbstractWriter//,  Abstract  Reader  [no  multiple  inheritance  yet] 
method  read  =  method  skip  =  .  .  . ;  method  close  =  .  .  .  //same  types  as  in  Reader 
method  append  =  method  write  =  method  flush  =  .  . .  //same  types  as  in  Writer 
method  seek:  ( )  ^  long  long  =  .  .  . 

) 

//may  use  all  methods  in  Reader,  Writer  and  also  seek 

let  readAndWrite  =  fn  (stream:  Reader  a  Writer  a  seek:  ( )  long  ^  long)  --> 
s.readj  s.seek  10 
s. write 'fj  s. flush 

readAndWrite  stringStream  //  typechecks 


Figure  2.4:  Adding  “writer”  definitions 


Using  intersection  types  (with  the  “a”  notation),  we  can  easily  combine  type  definitions.  The 
parameter  to  readAndWrite,  for  example,  must  be  a  subtype  of  both  Reader  and  Writer  and  also 
have  a  seek  method.  Since  StringStream  conforms  to  this  type,  it  may  be  passed  as  a  parameter 
to  readAndWrite. 


Adding  code  to  satisfy  a  structural  constraint.  I  have  described  how  function  and  method 
arguments,  including  the  receiver  of  internal  and  external  methods,  may  specify  structural 
constraints — methods  that  must  exist  in  addition  to  the  brand’s  defined  methods.  If  a  brand 
does  not  conform  to  this  structural  constraint,  external  methods  can  be  used  to  remedy  this 
situation. 

Figureja^shows  such  an  example.  Here,  I  have  defined  the  writeLine  external  method,  which 
is  applicable  to  any  AbstractWriter  that  provides  a  newline  method.  This  latter  method  is  expected 
to  return  the  newline  string  for  the  current  platform. 

Since  AbstractWriter  does  not  define  newline,  the  expression  writer. writeLine  does  not  type- 
check.  But,  once  we  have  added  newline  as  an  external  method  and  imported  it  into  the  current 
scope  (with  a  using  expression),  writeLine  may  be  called  on  any  object  of  type  AbstractWriter. 

Figure  [2^  shows  the  sub  typing  relationships  that  hold  as  a  result  of  the  brand  and  external 
method  definitions.  These  relationships  illustrate  why  the  example  code  typechecks  properly. 
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//external  method:  add  method  to  AbstractWriter, 

//  with  constraint  that  receiver  must  have  a  ‘newline’  method 
method  AbstractWriter.writeLine:  (newline:  ( )  =>  string)  =►  string  ^  unit  = 
fn  s:  string .  .// print  out ‘s,’ using '(\e\N\/me  method 

new  StringStream(  ).writeLine  “A2"  // doesn’t  typecheck — no  ‘newline’ method  in  StringStream 

method  AbstractWriter. newline:  ( )  =>  string  =  "\r\n" 

using  newline  in 

new  StringStream ( )  .writeLine  "42"  //  typechecks! 


Figure  2.5:  Adding  external  methods  to  conform  to  structural  constraints 


2.2.2  Example  2;  Collections 

The  second  example  regards  the  definition  and  implementation  of  “collection”  classes  (e.g.,  a 
map,  set,  etc.).  This  section  illustrates  how  abstract  methods  can  be  encoded  via  structural 
constraints  and  how  nominal  types  can  be  used  to  enforce  design  intent. 


Encoding  abstract  methods.  Using  structural  constraints  on  a  method’s  receiver,  we  can 
effectively  encode  abstract  methods.  The  first  benefit  of  this  encoding  is  that  it  simplifies  the 
formal  system;  we  need  not  include  abstract  methods  or  abstract  classes. 

To  illustrate  this  encoding,  consider  the  Java  class  definition  at  the  top  of  Fig.  2.7  which  is 
based  on  a  Java  1.5  Collections  Library  class.® 

To  translate  this  code  to  Unity,  the  abstract  methods  in  the  Java  class  are  converted  to  struc¬ 


tural  constraints  on  the  receiver  of  the  relevant  methods  (bottom  part  of  Fig.  2.7 1.  For  instance. 


contains  is  implemented  in  terms  of  iterator,  so  it  requires  that  its  receiver  have  the  latter  method; 
the  same  pattern  is  used  for  isEmpty  and  toString. 

Not  only  does  this  encoding  simplify  the  formal  system,  it  increases  the  language’s  flexibilty; 
a  structural  constraint  can  be  satisfied  using  either  an  internal  or  external  method.  Due  to  a 
restriction  on  the  definition  of  external  methods,  if  iterator  and  size  are  introduced  as  abstract 
internal  methods,  subclasses  can  only  provide  internal  method  implementations.  With  a  struc¬ 
tural  constraint,  however,  one  of  a  set  of  external  methods  definitions  may  be  chosen  to  satisfy 
it. 

In  particular,  the  restriction  is  that  external  methods  may  not  override  internal  methods 
(described  further  in  Sect.  2.4.2I.  As  a  consequence,  once  a  method  is  defined  as  an  “abstract” 
internal  method,  it  can  only  be  implemented  with  internal  methods  in  sub-brands. 

With  structural  constraints,  on  the  other  hand,  in  some  module  Mi,  we  may  define: 


*Note  that  not  I  am  not  using  parametric  polymorphism  here;  an  extension  of  Unity  with  this  feature  is 
outlined  in  Sect.  2.5.3  and  formalized  in  jMalayeri  and  Aldrldi  2008b). 


2.2.  Unity  by  Example 
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AbstractReader  <  Reader 
CharArrayReader  <  AbstractReader 
BufferedReader  <  AbstractReader 
SomeOtherReader  ^  AbstractReader 
SomeOtherReader  <  Reader 

CharArrayReader  <  AbstractReader(mark: ...,  reset: ...  ) 

StringStream  <  Reader 
StringStream  <  Writer 

Writer  a  seek  <  Writer 
StringStream  <  Writer  a  Reader  a  seek 

// after  a  ‘using’  expression 

new  StringStream( ):  StringStream(newline: ...  )  <  AbstractWriter(newline: ...  ) 


Figure  2.6:  Typing  and  subtyping  induced  by  the  brand  declarations.  Types  of  methods  are 
elided,  and  empty  structural  components  (i.e.,  ( ))  are  omited. 


//  ordinary  iterator  implementation 
method  iterator  AbstractList( ):  Iterator  =  .  .  . 
method  iterator  StoreBackedList( ):  Iterator  =  .  .  . 

Now,  suppose  that  in  another  module  M2,  we  have  a  different  implementation  for  iterator  (per¬ 
haps  one  that  caches  the  next  element  to  be  retrieved).  Then,  depending  on  which  external 
method  is  imported  through  the  “using”  expression  (Mi. iterator  or  M2. iterator),  different  exter¬ 
nal  method  definitions  can  be  “plugged-in”  to  a  particular  context.® 

This  feature  essentially  allows  different  external  methods  to  be  attached  to  existing  objects. 
This  is  reminiscent  of  mixins  |Bracha  and  Cook||i99o|  [Ancona  and  Zucca||i996|,  but  here  the 
“mix-in”  operation  occurs  at  the  object  level.  Sections [2^4^ and [2^ describe  the  formalization 
of  the  “using”  construct. 

Combining  structural  and  nominal  types.  Up  to  this  point,  we  used  brands  to  implement 
(internal  and  external)  methods.  But,  it  is  also  possible  to  use  brands  to  specify  and  enforce 
design  intent. 

In  particular,  let  us  consider  the  types  Collection  and  Set  from  the  Java  Collections  library. 
These  types  have  identical  interfaces,  but  are  not  necessarily  used  in  the  same  way.  In  particular, 
a  Set  does  not  have  duplicate  elements,  while  a  Collection  may. 

Unity’s  nominal  typing  component — brands — can  be  used  to  enforce  the  intent  that  an  ob¬ 
jects  should  have  a  particular  inheritance  path,  in  addition  to  having  methods  with  the  appro- 

®To  simplify  the  presentation,  the  “using”  expression  the  code  examples  did  not  specify  a  module,  but  this 
would  be  a  straightforward  extension. 
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//  Java  class  with  abstract  methods 
abstract  class  AbstractCollection  { 
abstract  Iterator  iterator ()j 
abstract  int  size()j 

boolean  contains(Object  o)  {  ...  }  //wses  iterator 
boolean  isEmpty()  {  ...  ]  // uses  s\ze 
String  toStringO  {  ...  ]  // Mses  iterator 

1 

//  Unity  translation 

type  Iterator  =  Object  (next:  ( )  Object  ( ),  hasNext:  ( )  bool) 

brand  AbstractCollection  ( 

method  contains:  (iterator:  ()  =►  Iterator)  =>  ObJect()  ->  bool  =  .  .  . 
method  isEmpty:  (size:  ( )  ^  int)  =►  bool  =  . .  . 
method  toString:  (iterator:  ( )  =►  Iterator)  =>  string  =  .  .  . 


Figure  2.7:  Translating  Java  abstract  methods  to  Unity  structural  constraints 


//same  method  types  as  in  AbstractCollection 

type  Collection  =  ObJect(contains: .  . . ,  isEmpty: . .  . ,  toString: . .  . ,  iterator: .  .  .,  size: . .  .  ) 

brand  SetBrand  ( )  //define  a  brand  to  distinguish  Set  from  Collection 

type  Set  =  SetBrand  (contains,  isEmpty,  toString,  iterator,  size)  //same  types  as  in  Collection 

//a  concrete  set  implementation 

brand  HashSet  extends  SetBrand  (...)  //declare  and  implement  Set  methods 

type  Map  =  Object  ( 
entrySet:  ( )  =>  Set 
values:  ()  =>  Collection 
...) 

let  useMap  =  fn  (m:  Map)  -->  let  set  =  m. entrySet  in  .  .  .  //  ‘set’ has  brand  SetBrand 


Figure  2.8:  Using  nominal  types  to  create  constraints 


2.2.  Unity  by  Example 
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type  Readable  =  Object(read:  ( )  =>  char) 
type  Writeable  =  Object(write:  ( )  ^  char  ^  int) 

method  Readable. foo  =  .  .  .  //(i) 
method  Writeable.foo  =  .  . .  //  (2) 

readWritable.foo  // ambiguous  method  call! 


Figure  2.9:  In  Unity,  dispatch  is  performed  on  brands,  since  structural  method  dispatch  would 
result  in  ambiguous  method  calls. 


priate  types.  Figure  [a^has  an  example  of  this.  Here,  in  the  useMap  function,  we  know  that  the 
variable  set  has  brand  SetBrand.  Since  an  object  cannot  implicitly  conform  to  this  type  (as  its 
brand  must  be  a  sub-brand  of  SetBrand),  this  can  help  prevent  “accidental”  subtyping. 

Note  that  SetBrand  has  not  defined  any  methods  as  it  is  conceptually  an  interface;  any  in¬ 
cluded  methods  would  be  “abstract.”  For  this  reason,  the  relevant  methods  have  instead  been 
moved  to  the  type  Set. 

I  refer  back  to  this  code  listing  in  Sectionja^below,  in  the  context  of  a  comparison  to  “where” 
clauses  in  Cecil. 


2.2.3  Discussion  and  Summary 

I  this  section,  I  discuss  issues  surrounding  Unity’s  dispatch  semantics  and  summarize  the  key 
features  of  the  language. 

Dispatch  Semantics 

In  Unity,  external  dispatch  may  only  be  performed  on  brands;  this  restriction  is  necessary  to 
make  ambiguity  checking  feasible.  As  a  counter-example,  suppose  we  were  to  allow  dispatch 
on  structural  types.  If  structural  types  Readable  and  Writeable  were  defined  as  in  Fig.  [2. 9]  we 
could  write  a  method  foo  that  behaves  differently  depending  on  whether  its  receiver  conforms 
to  the  Readable  type  or  the  Writeable  type  (an  admittedly  contrived,  though  illustrative,  method). 
Aside  from  making  it  difficult  to  efficiently  implement  method  dispatch  (in  the  worst  case,  the 
entire  structure  of  the  type  would  have  to  be  examined  at  runtime),  this  definition  is  ambiguous: 
what  if  foo  is  called  on  an  object  that  is  a  subtype  of  both  Readable  and  Writeable? 

If  dispatch  were  permitted  on  structural  types,  these  kinds  of  ambiguities  would  continually 
arise,  due  to  the  intrinsic  properties  of  structural  subtyping.  To  ensure  type  safety  in  such  a  case, 
the  typechecker  would  require  that  the  programmer  provide  disambiguating  methods  whenever 
there  is  any  potential  ambiguity  (based  on  the  static  structure  of  the  program);  this  is  the  only 
way  to  statically  prevent  all  runtime  ambiguities  in  a  modular  manner.^®  However,  this  approach 

^°I  am,  of  course,  assuming  that  it  is  unacceptable  for  the  runtime  to  arbitrarily  choose  one  of  the  candidate 
methods,  or  to  choose  a  method  based  on  the  textual  ordering  of  the  definitions. 
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is  infeasible:  for  a  particular  external  method,  the  number  of  required  disambiguating  methods 
is  exponential  in  the  number  of  implementations  dispatching  on  incomparable  types  (i.e.,  types 
where  neither  is  a  subtype  of  the  other).  The  need  for  disambiguating  methods  is  discussed 
further  in  Sect.|3.3|  in  the  context  of  “diamond”  multiple  inheritance. 

This  design  has  another  issue:  it  can  magnify  the  problem  of  accidental  subtyping.  Suppose 
we  were  to  have  the  following  declaration: 

method  Object. bar(x:  Ti  )  =  .  .  .  ®  //called  when  receiver  dynamically  has  method  ‘x’ 

method  Object. bar(x:  Ti,  y:  T2)  =  . .  .  ®  //called  when  receiver  dynamically  has  methods  ‘x’ and  ‘y’ 

This  definition  is  not  ambiguous  (in  the  sense  of  the  previous  example),  but  it  can  have  an  unex¬ 
pected  interaction  with  external  methods.  In  particular,  suppose  an  external  method  y  (with  the 
appropriate  type)  is  added  to  an  object  0  of  brand  C,  which  previously  had  only  an  x  method. 
Now,  calls  to  o.bar  will  change — code  fragment  (B)  will  be  executed!  This  is  the  same  sort  of 
problem  as  with  accidental  subtyping,  but  is  even  more  subtle  and  difficult  to  statically  diag¬ 
nose. 


Summary 

The  examples  illustrated  the  three  main  features  in  Unity:  structural  types,  nominal  types,  and 
external  dispatch: 

•  Structural  types  can  be  used  to  create  structural  constraints.  If  method  m  has  structural 
constraints  (mi  :  Ti,...,m„  :  t„),  the  expression  o.m  is  valid  only  if  o’s  structural  type 
contains  mi,...,  m„  with  types  conforming  to  (i.e.,  subtypes  of)  Ti,...,t„.^^ 

•  Nominal  types  are  used  to  create  a  new  brand  that  can  be  used  in  dispatch;  as  a  conse¬ 
quence,  programs  can  define  new  behavior  for  the  newly  defined  brand.  In  the  streams 
example,  CharArrayReader  is  defined  as  an  extension  of  AbstractReader  because  (for  exam¬ 
ple)  the  behavior  of  parse  is  different  for  each  type. 

The  programmer  can  also  use  brands  to  preserve  design  intent;  nominal  types  can 
be  used  to  distinguish  between  similarly-named  methods  that  behave  differently  (e.g., 
Cowboy.draw( )  and  Circle. draw( )).  This  was  shown  in  the  collections  example,  with 
SetBrand. 

•  External  dispatch  and  structural  sub  typing  have  synergistic  properties.  Structural  sub¬ 
typing  can  be  used  to  specify  the  constraints  of  a  method,  and  external  methods  can  be 
used  to  make  existing  brands  conform  to  those  constraints.  Additionally,  the  “using”  ex¬ 
pression,  in  conjunction  with  external  methods,  can  be  used  to  “plug-in”  different  internal 
method  implementations  to  different  contexts. 


’^^This  is  an  over-generalization  for  the  purposes  of  presentation.  As  we  will  see  in  the  formal  system 
(Sect.  2.5  ,  the  expression  o.m  is  also  valid  if  o’s  brand  contains  method  m. 


2.3.  Structural  Subtyping  and  Design  Patterns 
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2.3  Structural  Subtyping  and  Design  Patterns 

In  this  section,  I  consider  two  potential  applications  of  Unity:  expressing  three  commonly-used 
design  patterns,  and  redesigning  the  Java  Collections  Library  to  remove  “optional”  methods. 


2.3.1  GoF  Patterns  in  Unity 


Several  design  patterns  identified  by  [Gamma  et  al.||i994|  can  be  expressed  more  elegantly  in 
Unity  versus  mainstream  object-oriented  languages.  These  include  Visitor,  Proxy,  and  Decora¬ 
tor. 


The  need  for  Visitor  is  in  fact  obviated  in  Unity,  due  to  the  presence  of  external  methods. 
To  dispatch  on  an  existing  hierarchy,  the  programmer  simply  writes  new  external  methods  for 
those  brands  [Clifton  et  al.l2006l|Millstein|2003|. 

In  some  situations,  the  Proxy  and  Decorator  patterns  are  easier  to  implement  in  a  language 
with  structural  subtyping.  In  order  to  effectively  use  these  patterns  in  a  nominally-typed  lan¬ 
guage,  interfaces  must  be  defined  in  advance  for  the  classes  for  which  we  wish  to  define  a  proxy 
or  decorator.  If  no  appropriate  interface  exists,  these  patterns  may  be  impossible  or  unwieldy  to 
implement. 


Proxy.  The  Proxy  design  pattern  is  used  to  create  an  intermediary  to  an  object  to  be  used 
in  the  object’s  place.  The  object  in  question  may  be  expensive  to  create  or  should  perhaps  be 
accessed  in  a  particular  manner.  Examples  include  reference-counted  pointers  and  local  objects 
that  access  remote  resources. 

Suppose  we  wish  to  create  a  proxy  for  the  RealSubject  class,  which  implements  the  Subject 
interface.  The  typical  implementation  is  to  create  a  Proxy  class  that  also  implements  Subject 
and  has  a  field  of  type  RealSubject.  Proxy  can  then  forward  method  calls  to  the  RealSubject  field, 
possibly  performing  additional  operations  before  and  after  the  method  call. 

This  implementation  depends  on  the  existence  of  the  Subject  interface;  without  such  an 
interface,  problems  will  arise.  Concretely,  suppose  we  have  a  class  Rasterlmage  that  does  not 
implement  any  interfaces.  If  we  were  to  use  a  traditional  nominally-typed  language,  the  new 
RasterlmageProxy  class  would  have  to  extend  Rasterlmage  and  re-implement  the  necessary 
methods.  Inheritance  would  be  necessary  here,  in  order  to  obtain  the  appropriate  subtyping 
relation.  But,  there  is  a  problem  if  Rasterlmage  loads  the  image  into  memory  in  the  constructor, 
since  the  RasterlmageProxy  constructor  must  call  the  Rasterlmage  constructor.  This  would  then 
make  it  impossible  for  RasterlmageProxy,  for  example,  to  perform  lazy  loading  of  the  image  file. 

This  problem  does  not  occur  with  a  language  that  separates  inheritance  and  subtyping, 
like  Unity.  In  such  languages,  well-designed  code  would  never  mention  the  nominal  type 
Rasterlmage  directly  (except  when  creating  an  object),  and  would  instead  use  a  type  whose  struc¬ 
tural  component  consisted  of  the  methods  of  Rasterlmage.  (Analogously,  in  a  nominally-typed 
language  that  separates  inheritance  and  subtyping,  the  type,  rather  than  the  class,  corresponding 
to  Rasterlmage  would  be  used.)  Then  RasterlmageProxy  need  not  inherit  from  Rasterlmage,  but 
would  instead  have  a  field  of  type  Rasterlmage — the  usual  implementation  of  the  Proxy  design 
pattern. 
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Decorator.  A  similar  situation  arises  with  the  Decorator  design  pattern.  Decorator  is  often 
used  when  we  wish  to  add  new  or  additional  behavior  to  an  existing  class.  The  pattern  is  imple¬ 
mented  by  creating  a  new  class  that  “wraps”  the  original  class  and  forwards  method  calls  to  it. 
To  create  a  decorator  for  a  ConcreteComponent  class  that  implements  the  IComponent  interface, 
we  would  create  a  class  Decorator  containing  a  field  of  type  IComponent.  Similar  to  proxy,  the 
Decorator  class  can  forward  calls  to  this  field,  possibly  performing  additional  behavior  before  or 
after  the  method  call.  (Note  that  though  the  implementation  of  Proxy  and  Decorator  is  similar, 
the  decorated  object  often  changes  dynamically,  whereas  a  proxy  does  not  typically  change  its 
subject  object.)  Decorators  are  often  used  to  attach  new  behavior  to  GUI  objects,  such  as  adding 
a  scrollbar  or  border.  The  Java  stream  library  also  uses  decorators  to  implement  functionality 
such  as  buffering  and  encryption. 

As  with  Proxy,  traditional  languages  can  make  it  difficult  to  implement  Decorator  when  the 
ConcreteComponent  class  does  not  implement  a  suitable  interface.  The  workaround  is  to  create 
a  class  Decorator  that  inherits  from  ConcreteComponent  (in  order  to  obtain  subtyping),  and  also 
defines  a  ConcreteComponent  field.  But,  this  design  will  only  work  if  ConcreteComponent  has  not 
been  declared  as  final.  Additionally,  in  this  awkward  design,  unused  resources  may  be  created. 
Programmers  must  also  take  care  to  never  call  methods  in  ConcreteComponent  on  the  this  object, 
but  rather  on  the  declared  ConcreteComponent  field. 

Again,  if  inheritance  and  subtyping  are  distinct  features,  client  code  would  use  the  type 
ConcreteComponent  (rather  than  the  class),  and  Decorator  would  declare  itself  a  subtype  (but 
not  a  subclass)  of  ConcreteComponent.  With  structural  subtyping,  the  code  is  even  simpler,  as 
Decorator  need  not  declare  a  relationship  to  ConcreteComponent. 


Concretely,  the  code  for  a  typical  Java  Decorator  implementation  is: 


interface  IComponent  {  void  doSomething( ) j  ] 

class  ConcreteComponent  implements  IComponent  {  void  doSomething( )  {  ...  ]  ] 

class  Decorator  implements  IComponent  { 

IComponent  wrapped; 

void  doSomethingO  { 

...  // set-up  code 
wrapped . doSomethingO  I 
. . .  //  tear-down  code 

} 

} 


The  corresponding  code  in  Unity  would  be: 


2.3.  Structural  Subtyping  and  Design  Patterns 


29 


brand  ConcreteComponent  (method  doSomething( ):  unit  =  .  . .  ) 
brand  Decorator  ( 

wrapped:  Object(doSomething:  ( )  =►  unit) ; 
method  doSomething  ( ) :  unit  = 

.  .  .  //set-up  code 
wrapped. doSomething 
.  .  .  //  tear-down  code 

) 


2.3.2  Optional  Methods  in  the  Java  Collections  Library 


In  this  section,  I  describe  the  tradeoffs  that  a  library  designer  must  make  when  using  a  language 
that  has  only  nominal  subtyping.  The  design  of  the  Java  collections  library  illustrates  that  de¬ 
signers  would  rather  circumvent  the  type  system  than  have  a  proliferation  of  types.  I  believe  this 
situation  can  occur  all  too  often  in  a  language  with  only  nominal  subtyping.  Chapter  [^presents 
empirical  evidence  to  support  this  claim. 

In  the  Java  collections  library,  the  interface  Java. util. Collection  has  several  “optional” 
methods:  add,  addAII,  clear,  remove,  removeAll,  and  retainAII.  Many  of  the  abstract 
classes  implementing  Collection  (e.g.,  AbstractCollection,  AbstractList,  AbstractSet)  throw  an 
UnsupportedOperationException  when  those  methods  are  called.  There  are  a  total  of  30  op¬ 
tional  methods  in  Java. util.*,  and  Java. lang. Iterator  has  an  additional  optional  method.  The 
methods  were  designed  this  way  to  avoid  an  explosion  of  interfaces  such  as  MutableCollection, 
ImmutableCollection,  etc.,  and  a  corresponding  increase  in  the  number  of  sub-interfaces  (e.g., 
MutableList,  ImmutableList,  etc.)  |Sun  Microsystems  2003 1. 

Let  us  consider  a  Java  collections  framework  without  the  optional  methods.  Figure  2.10 
shows  a  relevant  portion  of  the  current  Java  collections  hierarchy.  Figure  2.ii|show  refactored 


AbstractList  and  AbstractSet  classes  with  finer  grain  behavior,  with  new  interfaces  that  capture  the 
distinction  of  modifiability  directly  in  the  hierarchy — doing  away  with  optional  operations.  The 
portions  of  AbstractList  that  pertained  to  mutability  have  been  moved  to  AbstractModifiableList; 
the  same  for  AbstractModifiableSet.  The  interface  Collection<E>  represents  a  collection  that  is 
possibly-modifiable,  while  ModifiableCollection<E>  represents  a  collection  that  can  be  modified. 
Accordingly,  its  iterator()  method  returns  a  Modifiablelterator.  This  new  Iterator  interface  is 
depicted  in  Figure  The  Iterator<E>  interface  has  been  changed  so  that  it  no  longer  has  a 
remove ( )  operation;  this  method  has  been  moved  to  IVIodifiableIterator<E>.  There  are  now  two 
new  Listiterator  interfaces,  one  for  fixed-size  lists,  and  one  for  variable-size  lists.  These  cor¬ 
respond  to  the  ModifiableFixedSizeList<E>  and  ModifiableList<E>  interfaces  in  Figure [2ni|  The 
hierarchy  for  Set  is  similar  to  that  of  List  (though  simpler,  since  there  are  no  fixed-size  sets,  and 
no  set-specific  iterator). 

shows  the  refactored  Map  interface  and  related  classes.  The  main  interface  here 


Figure 
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is  Map<K,V>  which  has  a  method  entrySet( ) .  In  the  original  collections  hierarchy,  this  returns  a 
Set<Map.Entry>,  but  the  documentation  states  that  the  returned  set  supports  only  set  removal 
operations,  not  set  addition  operations.  So,  an  additional  interface  is  needed  for  a  set  that  sup- 
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Figure  2.10:  A  portion  of  the  Java  collections  framework.  Only  a  subset  of  an  interface’s  meth¬ 
ods  are  listed.  Type  parameters  are  elided  in  classes. 


ports  modification  only  through  remove  operations;  this  is  represented  by  RemovableSet  in  Fig- 
Another  interface  is  needed  for  a  general  collection  (as  opposed  to  a  set)  that  supports 


ure 


2.14 


element  removal,  since  the  method  values  ( )  returns  an  object  of  such  a  type.  This  is  represented 


by  RemoveableCollection  (also  in  Figure  2.14 1. 

As  noted,  in  the  original  design  entrySet()  returns  type  Set<IVlap.Entry>.  This 
translates  into  four  possibilities  in  the  refactored  hierarchy:  Set<Map.Entry>  (a  read¬ 
only  set  with  read-only  entries),  RemovableSet<Map.Entry>  (a  mutable  set  with  read¬ 
only  entries),  Set<ModifiableMap.Entry>  (a  read-only  set  with  mutable  entries),  and 
RemovableSet<IVlodifiablelVlap.Entry>  (a  mutable  set  with  mutable  entries).  This  is  due  to 
the  fact  that  Map. Entry. setValue  is  an  optional  method,  and  thus  needs  a  new  interface  to 
capture  its  behavior.  Aside  from  this  proliferation  of  interfaces,  the  class  diagram  for  Map  is 
fairly  straightforward. 


Utility  of  structural  subtyping.  In  a  language  with  structural  subtyping,  such  as  Unity,  not 
all  interesting  combinations  of  types  have  to  be  declared  in  advance  (though  in  a  library  setting 
they  might  be,  for  consistency’s  sake).  However,  the  key  idea  is  that  a  type  alias  would  simply 
be  syntactic  sugar  for  a  set  of  methods,  which  could  be  given  a  different  type  alias  in  a  different 
part  of  the  system.  Additionally,  the  subtyping  relationships  between  all  the  interfaces  would 
not  need  to  be  defined  in  advance.  Finally,  as  a  side  note,  the  notational  overhead  in  defining 
type  aliases  would  be  potentially  far  lower  than  that  of  defining  a  Java  interface,  which  has  a 
relatively  high  notational  cost  (due,  in  part  to  the  nominal  nature  of  interfaces). 

In  the  FAQ  for  the  Java  collections  API  design  |Sun  Microsystems  2003),  in  explaining  the 
rationale  for  the  optional  methods,  examples  are  given  for  additional  interfaces  that  would  be 
useful.  One  example  is  that  of  logs,  such  as  error  logs  and  audit  logs.  As  these  are  append-only 
sequences,  they  should  support  all  of  the  List  operations  except  for  remove  ( )  and  set( )  (replace 
value).  For  a  Java  implementation,  this  would  require  a  new  core  interface,  and  a  new  iterator 
interface. 
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Figure  2.11:  Refactored  AbstractList  and  AbstractSet  classes,  along  with  new  interfaces  to  re¬ 
move  optional  methods.  Only  a  subset  of  an  interface’s  methods  are  listed.  Type  parameters 
are  elided  in  classes. 


Another  example  given  in  the  FAQ  is  that  of  immutable  collections — ones  that  cannot  be 
modified  by  any  client,  not  just  through  the  current  reference.  This  kind  of  type  can  be  useful 
because  it  doesn’t  require  synchronization.  However,  to  support  such  invariants  in  the  library, 
4  additional  core  interfaces  are  need,  plus  additional  iterator  interfaces. 

It  is  interesting  to  note  that  these  two  examples  in  the  FAQ  do  not  arise  naturally  from  the 
design  of  the  collections  library — they  are  design  considerations  that  might  be  useful.  This  high¬ 
lights  the  mindset  of  the  Java  developer:  since  everything  must  be  defined  in  advance,  any  po¬ 
tentially  useful  interface  must  be  considered  ahead  of  time  and  its  advantages  carefully  weighed. 


2.4  Methods  in  Unity 

This  section  presents,  at  a  high  level,  the  properties  of  methods  in  the  Unity  formal  system.  I 
describe  the  semantics  of  method  dispatch,  rules  for  typechecking  external  methods,  and  the 
naming  convention  for  internal  and  external  methods. 
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Figure  2.12:  Refactored  iterator  interfaces.  All  methods,  except  for  inherited  methods,  are 
shown. 


Figure  2.13:  Refactored  AbstractMap  class,  along  with  new  interfaces  to  remove  optional  meth¬ 
ods.  Only  a  subset  of  an  interface’s  methods  are  listed.  Type  parameters  are  elided  in  classes. 


2.4.1  Dispatch  Semantics 

Methods  may  be  defined  with  structural  constraints,  but  these  constraints  are  not  used  in 
dispatch — only  brands  are  used.  Thus,  it  is  invalid  to  define  two  methods  with  the  same  name 
and  that  dispatch  on  the  same  brand,  with  differing  structural  constraints.  Therefore,  when 
overriding  a  method  m,  a  subclass  may  not  add  structural  constraints  to  m’s  receiver  or  its  ar¬ 
guments.  Similarly,  it  is  not  possible  to  providde  two  definitions  for  an  external  method  C.  m. 


2.4.2  External  Method  Definitions 

Recall  that  in  Unity,  external  methods  may  be  overridden  by  other  methods,  either  internal  or 
external.  Typechecking  an  external  method  has  two  components:  exhaustiveness  checking  (the 
provided  cases  provide  full  coverage  of  the  dispatch  hierarchy)  and  ambiguity  checking  (when 
executing  a  given  method  call,  only  one  method  is  applicable). 
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Figure  2.14:  RemovableCollection  and  RemovableSet.  Interfaces  have  been  repeated  from  other 
figures  to  show  subtyping  relationships;  these  have  been  grayed  out.  Only  a  subset  of  an  inter¬ 
face’s  methods  are  listed. 


I  have  adapted  the  restrictions  on  external  methods  that  were  enforced  by  Millstein  and 
Chambers’  “System  M”  variant  of  the  Dubious  calculus  [Millstein  and  Chambers||2002|,  and  by 
later  extensions  such  as  Multijava  |Clifton  et  al.|20oo1  and  EML  [Millstein  et  al.|20^ 


2004] 


In  Unity,  exhaustiveness  of  external  methods  is  ensured  because  there  are  no  abstract  meth¬ 
ods.  If  such  a  feature  were  present,  external  method  definitions  would  not  be  permitted  to  be 
abstract — just  as  in  the  aforementioned  languages. 

Additionally,  to  allow  modular  ambiguity  checking.  Unity  methods  must  obey  the  following 
rules: 


El.  All  external  method  definitions  of  a  method  m  must  appear  in  the  method  block  where  the 
method  family  m  is  introduced  (using  the  method  declaration). 

E2.  An  external  method  definition  may  not  override  an  internal  one  (though  an  internal  method 
may  override  an  external  one). 

£3.  When  an  external  method  family  m  is  introduced,  it  must  declare  an  owner  brand  C:  this 
specifies  that  the  method  family  is  rooted  at  C.  C  must  be  a  proper  subtype  of  Object,  the 
root  of  the  inheritance  hierarchy.  An  external  method  definition  m  for  brand  D  is  valid 
only  if  D  is  a  snh-brand  of  C. 

Here,  a  method  family  is  defined  as  a  method  and  all  of  its  overrides.  For  internal  methods,  the 
overrides  are  spread  across  multiple  classes,  but  for  external  methods,  condition  £i  ensures  that 
the  external  declarations  in  the  family  appear  in  the  same  syntactic  block. 

Condition  Ei  is  necessary  because  otherwise  there  could  be  two  external  method  definitions 
m  defined  for  the  same  brand  C,  leading  to  an  ambiguity.  This  ambiguity  would  be  impossible  to 
detect  in  a  modular  manner,  since  when  checking  particular  external  method,  the  typechecker 
would  have  to  do  a  non-modular  search  for  other  external  methods  with  the  same  name.  (Note 
that  in  the  code  examples,  all  external  method  definitions  appeared  together,  though  for  brevity 
a  method  block  was  not  used.) 
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Condition  £2  is  required  to  avoid  a  situation  where  two  external  methods  override  the  same 
internal  method.  Since  neither  external  method  is  “better”  than  the  other,  this  would  result  in  a 
run-time  method  lookup  ambiguity. 

Finally,  condition  £3  is  necessary  for  ambiguity  checking  in  the  presence  of  multiple  inheri¬ 
tance,  and  will  be  described  further  in  Sect.|3.4.^  For  this  reason,  the  owner  brand  was  omitted 
from  the  previous  examples. 


2.4.3  Simple  and  Qualified  Method  Names 

Until  now,  I  have  glossed  over  the  details  of  method  naming,  but  as  it  turns  out,  to  correctly 
implement  condition  £2  (in  a  modular  fashion),  the  formal  system  must  have  a  way  of  distin¬ 
guishing  between  external  and  internal  method  names. 

Concretely,  suppose  we  have  an  external  method  m  defined  on  brand  A.  Now,  we  add  brand 
B  that  extends  A.  Ffere,  B  is  permitted  to  also  define  a  method  named  m  (with  a  different  type, 
even)  if  the  definition  of  A.m  is  not  in  scope.  Next  suppose  than  an  object  0  tagged  with  B  is 
passed  to  a  context  where  A.m  has  been  imported,  and  we  call  o.m.  Now,  the  runtime  seman¬ 
tics  needs  to  be  able  to  distinguish  the  external  method  from  the  internal  method — otherwise 
either  method  is  equally  applicable.  One  straightforward  way  to  achieve  this  is  to  internally  use 
different  names  for  each  method. 

Consequently,  the  calculus  distinguishes  between  qualified  names  (denoted  by  the  metavari¬ 
able  q)  and  simple  names  (denoted  by  n).  The  qualified  name  of  a  method  family  (i.e.,  a  method 
and  all  of  its  overrides)  is  assumed  to  be  globally  unique.  This  can  be  easily  implemented  by 
generating  a  qualified  name  that  includes  the  brand  where  the  method  family  is  first  introduced. 
For  example,  an  internal  method  m  introduced  in  brand  B  (i.e.,  a  new  m  declaration,  rather 
than  an  override)  could  have  simple  name  m  and  qualified  name  B_m.  For  external  methods, 
the  owner  brand  of  an  external  method  block  can  be  used  to  generate  the  qualified  name  (e.g., 
C#m)."^ 

In  order  for  structural  subtyping  to  be  useful,  we  must  use  simple  names  for  the  structural 
component  of  a  type.  That  way,  if  two  unrelated  brands  B  and  C  each  have  methods  with  simple 
name  n  and  type  r  (and  corresponding  qualified  names  B  n  and  C_n),  the  simple  name  n  should 
be  used  in  so  that  objects  of  each  brand  are  subtypes  of  Object(n :  t).  In  contrast,  if  the  qualified 
names  were  used,  the  only  common  supertype  of  B  and  C  would  be  Object!).  Simple  names  are 
also  needed  for  external  methods,  to  support  the  pattern  of  adding  a  new  external  method  n :  t 
so  that  objects  of  an  existing  brand  D  conform  to  type  Din :  r).  An  example  of  this,  the  newline 
method,  was  presented  in  Fig.ja.sj 

Accordingly,  in  the  calculus,  each  object  contains  a  map  from  simple  name  to  qualified  name. 
This  mapping  can  be  either  specified  when  the  object  is  created,  or  can  be  added  to  an  existing 
object  via  the  with  expression,  described  below.^^ 

^^This  does  not  imply  that  owner  brands  are  necessary  for  modular  typechecking  in  the  absence  of  multiple 
inheritance;  an  “owner”  can  always  be  automatically  generated  by  taking  the  least  upper  bound  of  the  brands 
on  which  the  external  method  m  is  defined. 

’^^Note  that  in  the  formal  system,  the  simple  and  qualified  names  need  not  have  any  relation  to  one  another, 
while  in  an  actual  implementation,  the  simple  name  would  probably  be  a  sub-string  of  the  qualified  name. 
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Only  simple  names  appear  in  the  structural  component  of  a  type;  that  is,  types  are  of  the  form 
B[n :  t).  If  an  object  o  has  this  type,  the  method  call  o.rii  is  a  valid  expression.  Additionally,  any 
internal  or  external  method  defined  on  B  may  be  called  on  o,  using  qualified  names  (i.e.,  o.q). 

Note  that  qualified  method  lookup  can  be  easily  implemented  efficiently  (e.g.,  using  vta- 
bles),  whereas  simple  name  lookup  must  use  the  aforementioned  map  (and  is  more  difficult  to 
implement  efficiently,  due  to  depth  and  width  sub  typing).  There  is  a  benefit  to  this  design:  since 
simple  names  are  useful  primarily  for  the  structural  subtyping  aspect  of  the  system,  structural 
subtyping  becomes  a  “pay-as-you-go”  feature.  There  is  only  a  (potential)  performance  penalty 
if  and  when  it  is  used. 

Only  the  formal  system  includes  both  names;  in  the  surface  syntax,  the  programmer  would 
only  use  the  simple  name  and  the  qualified  name  would  be  automatically  generated.^"*^  An  elab¬ 
oration  phase  (described  below)  would  substitute  simple  names  for  qualified  names  where  pos¬ 
sible,  and  would  otherwise  generate  “with”  expressions  (or,  when  possible,  set  up  the  simple-to- 
qualified  mapping  when  objects  are  created).  The  using  expression,  which  appears  only  in  the 
surface  syntax  of  the  examples,  would  be  used  to  determine  which  external  methods  should  be 
used  to  generate  the  mapping. 

A  “with”  expression  must  be  generated  whenever  the  typechecker  must  coerce  an  already- 
created  object  to  a  structural  type.  For  instance,  in  Fig.  EH  a  BufferedReader  object  is  coerced 
to  Reader  in  order  to  call  findString.  The  elaborator  would  report  an  error  in  the  case  where  the 
same  simple  name  can  be  mapped  to  two  (or  more)  different  qualified  names. 

Concretely,  recall  the  highlighted  lines  of  Fig. 

findString  bufReader  "foo" 
findString  charArrayReader  "bar" 
findString  someOtherReader  "baz" 

Considering  only  the  read  method,  this  would  be  elaborated  to: 

findString  (bufReader  with  read  ^  AbstractReader_read, .  .  .  )  "foo" 
findString  (charArrayReader  with  read  ^  AbstractReader_read, .  .  .  )  "bar" 
findString  (someOtherReader  with  read  ^  SomeOtherReader_read, .  . .  )  "baz". 

Note  that  the  with  clause  for  charArrayReader  is  identical  to  that  of  bufReader;  this  is  because 
read  was  introduced  in  AbstractReader. 


readAndWrite  stringStream 
would  be  translated  to 


Similarly,  the  highlighted  line  in  Fig. 


2.4 


2.1 


^■^Additionally,  a  scope  qualifier  construct  would  also  be  necessary  to  distinguish  between  two  methods 
with  the  same  simple  name  (which  can  occur  either  through  multiple  inheritance  or  importing  of  external 
method  definitions).  The  explicit  use  of  qualified  names  in  the  formal  system  sidesteps  these  issues. 
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readAndWrite 

(stringStream  with 

read  ^  StringStream_read, .  .  . ,// Reader  methods 
append  ^  AbstractWriter_append, .  .  . ,// Writer  methods 
seek  ^  StringStream_seek 

)• 


Finally,  the  highlighted  line  of  Fig. 


2.5 


new  StringStream  ( )  .writeLine  "42" 


translates  to 

new  StringStream(newline  ^  AbstractWriter#newline)  .AbstractWriter#writeLine  "42". 


Finally,  note  that  in  a  system  with  state  (my  formal  system  is  purely  functional),  the  “with”  con¬ 
struct  would  create  a  wrapper  containing  the  new  mapping  along  with  a  pointer  to  the  old  object. 
In  such  a  system,  there  would  be  three  notions  of  equality:  wrapper  equality  (“==”  in  Java-like 
languages),  reference  equality,  and  value  equality  (equals  ()  in  Java).  Wrapper  equality  would 
consider  an  object  and  its  wrapped  variant  to  be  distinct,  while  reference  equality  would  equate 
two  wrappers  that  point  to  the  same  object  but  that  perhaps  have  different  simple-to-qualified 
name  mappings.  (This  latter  notion  should  perhaps  be  called  “equality,”  as  it  does  not  preserve 
contextual  equivalence.  That  is,  if  Oi  “unwrap-equals”  02,  this  does  not  mean  that  Oi.m  and  02-m 
will  call  the  same  method  Regardless,  I  believe  there  are  situations  in  which  such  a  notion 
of  “equality”  could  be  useful.) 


2.5  Formal  System 


The  Unity  grammar  is  presented  in  Fig.  2.15  The  language  is  a  lambda  calculus  with  the  addition 


of  values  tagged  with  brands.  The  metavariables  B,  C,  D,  and  E  range  over  brand  names,  and  the 
overbar  notation  (e.g.,  B)  denotes  a  sequence  of  items  (e.g.,  names,  types,  labels,  etc.)  that  may  be 
indexed  by  a  variable.  That  is,  B  is  equivalent  to  5,-  where  x  is  the  length  of  the  B  sequence. 
The  metavariables  n  and  q  ranges  over  simple  and  qualified  method  names,  respectively;  m 
ranges  over  both  kinds  of  method  names.  M  and  N  range  over  a  sequence  of  (method  :  type) 
pairs  (with  simple  names).  There  is  a  slight  abuse  of  notation  by  using  the  set  inclusion  operator 
on  lists  (e.g.,  m  e  m),  but  the  intended  meaning  should  always  be  clear  from  context. 

Portions  of  the  formal  system  are  highlighted  — these  are  the  aspects  of  the  language  per¬ 
taining  to  multiple  inheritance.  These  features  will  be  described  in  Sect. 


3-7 


To  define  a  brand,  the  brand  top-level  declaration  is  used.  When  a  brand  is  defined,  it  is 
given  a  name,  as  well  as  the  brand’s  field  type  (usually  a  record);  this  is  the  type  of  the  fields  of 
the  brand.  An  object’s  field  value  is  initialized  when  the  object  is  created. 


^^That  is  to  say,  all  unwrap-equal  objects  are  created  (quote-unquote)  “equal,”  but  some  are  more  equal 
than  others. 
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Programs 

p: 

:=  Z[>  decl  in  p  \  e 

Declarations 

decl: 

:=  brand-decl  \  method-decl 

Brand  declaration 

brand-decl 

=  brand  B[t,  m-decl)  extends  Ci,...,C„  requires  D 

Method  declaration 

m-decl 

=  q  Bln  ■■  p):t  =  e 

External  method  block 

method-decl 

-  method  B  .q{m-dect} 

Expression  types 

T,G 

=  unit  1  T  ^  T  1  T  AT  1  Bln :  p)  \{(  :r}\X  \  pX.T 

Method  types 

p 

=  ln:p}^T 

Expressions 

e 

=  0  1  a:  1  Xx-T.  e  1  ee  1  Ble;  n^q)\  e  with  n^q\lf 

1  e.m\  e.B.super.q  | fold^ e |  unfold^ e 

Values 

V- 

0  1  Blv;  n^q)\l(  =  v)\  Xx:r.  e  \  fold^  v 

Contexts 

T: 

:=  ■  |r,x:T|r,x<y 

Z: 

:=  •  1  T,  decl-type 

decl-type- 

:=  brand  Blr-,q-  p)  extends  C  requires  D 

1  method  B  .qlC.q--  p] 

A: 

:=  •  1  A,Blq=  e)  extends  C  |  method  qlB.q  =  e) 

Definitions 

d.ef 

fieldType^CB)  =  t  where  B{t ;...)■■■  eZ 

„  def 

B  =  type  corresponding  to  tag  B 

£,  k  range  over  record  label  names 
B,  C,  D,  E  range  over  brand  names 
n  ranges  over  “simple”  (non-unique)  method  names 
q  ranges  over  qualified  method  names 
m  ranges  over  n,q 
M,  N  range  over  n :  p 
Q  ranges  over  q:  p 
r  ranges  over  (,  k,  m 
t  ranges  over  r,  p 


Figure  2.15:  Unity  grammar.  The  portions  relating  to  multiple  inheritance  are  highlighted  and 
will  be  discussed  in  ChapterRj 
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Methods  can  be  defined  on  a  brand  either  externally  or  internally  and  the  usual  object- 
oriented  method  dispatch  semantics  apply/®  Like  brand  declarations,  external  method  dec¬ 
larations  are  top-level.  Note  that  condition  Ei  is  enforced  syntactically — all  external  method 
definitions  must  appear  in  the  same  block.  To  support  multiple  inheritance,  method  blocks  also 
contain  an  owner  brand;  the  need  for  this  is  discussed  further  in  Chapter 

It  is  important  to  note  that  top-level  declarations  decl  (brand  or  external  method)  are  each 
declared  with  a  context  Z.  This  is  the  context  under  which  the  brand  or  external  method  is  to  be 
typechecked;  it  must  contain  all  declarations  on  which  decl  statically  depends.  This  context  is 
included  for  two  reasons:  first,  in  a  real  program,  dependencies  between  modules  are  specified 
by  the  user  (or  inferred  by  the  module  system).  Next,  this  eases  the  modularity  proof  (described 


in  Sect.  3.7.3 1,  which  demonstrates  that  declarations  can  be  separately  typechecked  under  their 
declared  context  and  no  additional  checks  (analogous  to  link-time  checking)  is  necessary.2 
As  previously  described,  methods  take  only  one  argument:  the  receiver  (i.e.,  the  this  param¬ 
eter).  Additional  parameters  may  be  specified  using  lambda  expressions.  When  a  method  q  is 
defined  for  a  brand  B,  the  structural  constraint  M  (a  sequence  of  {method  :  type}  pairs)  is  spec¬ 
ified  for  the  receiver:  these  are  the  methods  that  must  exist  as  part  of  an  object  o’s  structural 
type  in  order  for  o.q  to  be  well-typed. 

The  calculus  distinguishs  between  expression  types  (denoted  by  t  and  a)  and  method  types 
(denoted  by  p).  Method  types  use  the  arrow  while  function  types  use  arrow 

The  language  includes  a  limited  form  of  intersection  types,  which  increase  expressiveness 
and  simplify  some  aspects  of  the  formal  system.  Section  2.5.1  describes  intersection  types  in 


more  detail.  Iso-recursive  types  are  also  included;  these  have  the  standard  fold  and  unfold  ex¬ 
pressions  with  the  usual  static  and  dynamic  semantics. 

If  B  is  a  brand  name,  then  B  is  the  tag  value  corresponding  to  B.  Values  also  contain  the 
simple-to-qualified  mapping  described  in  the  previous  section.  To  create  objects,  the  expression 
form  B[e,n^  q)  is  used;  this  creates  an  object  tagged  with  B  that  has  type  B(n :  t),  where  each 
qi  has  type  t,. 

To  modify  an  object’s  mapping  after  it  has  been  created,  the  with  expression  is  used.  This 
adds  mappings  W^Tq  to  the  object,  replacing  any  existing  mappings  that  have  the  same  simple 
name  and  are  associated  with  the  object  value. 

Z  is  the  brand  context;  it  stores  the  declared  brand  and  method  types.  A  is  the  corresponding 
run-time  context.  A  retains  method  bodies  but  discards  all  type  information  (with  the  exception 
of  brand  tags).  As  in  Featherweight  Java  [Igarashi  et  al.'igg^,  the  system  assumes  the  existence 
of  a  special  brand  Object  that  is  not  defined  in  Z  or  A,  but  that  may  be  extended  by  user-defined 
brands.  Since  every  brand  must  have  (at  least)  one  super-brand,  the  brand  subtype  hierarchy  is 
rooted  at  Object.^^ 

Note  that  the  context  Z  and  A  are  sometimes  omitted  from  the  rules  where  it  is  obvious  from 
the  manner  in  which  they  are  used;  in  such  cases,  the  required  context  is  an  unchanged  “Z”  or 


’^^Note  that  in  the  formal  system,  the  syntax  for  internal  method  declarations  mirrors  that  of  external 
method  declaration;  in  constrast,  in  the  code  examples,  internal  methods  have  syntax  “m-.p-  e.” 

^^Note  that  an  alternative  design  is  also  possible:  classes  that  extend  no  other  class  form  a  forest  with  no 
common  ancestor.  One  advantage  of  this  design  is  that  then  there  would  be  no  need  for  special-case  rules  for 


Object  (e.g.,  premise  (1)  of  Tp-Ext-Method  in  Fig.  2.19  . 
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Sub-brand  judgement 


(Sub-Brand-Refl) 

B^zB 


(Sub-Brand-Trans) 
Bi  Ex  Bz  Bz  Ei  Bz 


Bi  El  Bz 


(Sub-Brand-Decl) 

B[r;  Q)  extends  Ci, . . . ,  C„  e  Z 
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F  Hj;  ra-ta<rb-.  tb 


Sub-row  judgement 


(Sub-Row-Perm) 

r,- :  ti  is  a  permutation  of  rj  :  tj  " 
r  H  r,- :  ti  <  rj  :  tj 


(Sub-Row-Width) 
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(Sub-Row-Depth) 
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(Sub-Row-T  rans) 
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r  ^ra-ta<rc-tc 


Figure  2.16:  Sub-brand  and  sub-row  judgements 


“A”.  Judgements  that  are  also  functions  (such  as  mtype^,  mbody^,  etc.)  are  subscripted  with  the 
appropriate  context,  while  other  judgements  use  a  subscript  on  the  turnstile  symbol  (i.e.,  “1-2”). 

Like  many  other  object  calculi,  Unity  is  purely  functional  so  as  to  simplify  the  formal  system. 
State  is  orthogonal  to  the  issues  under  consideration  (with  the  exception  of  the  with  expression 
on  imperative  objects,  which  was  described  in  Sect.  2.4. 3|.  There  does  not  appear  to  be  any 
inherent  reason  why  the  language  design  could  not  be  adapted  to  a  language  with  imperative 
features. 

The  static  and  dynamic  semantics  of  Unity  (excluding  multiple  inheritance  features)  are  de¬ 
scribed  below;  a  discussion  of  the  proof  of  type  safety  appears  in  Sect.|3.7.^(with  full  proof  in  Ap¬ 
pendix]^.  Additionally,  a  proof  of  the  modularity  of  the  type  system  is  presented  in  Sect.  [3.7.3 


2.5.1  Static  Semantics 


In  this  section,  the  subtyping  and  typing  judgements  shown  in  Figs, 
described.  Auxiliary  judgements  are  in  Figs. 


2.20 


and 


2.22 


2.16 


2.17 


2.18  and 


2.21 


are 


Subtyping 


Unity  contains  three  distinct  sub-“type”  relations:  sub-brand  (Ex),  sub-row  (<)  and  subtype  (<). 
Sub-branding  (Fig.  2.i6|  is  not  on  types  but  rather  brands,  which  are  a  component  of  an  object 
type.  This  relation  is  simply  the  reflexive,  transitive  closure  of  the  declared  extends  relation. 
The  sub-row  relation  corresponds  to  Definition  2.2  it  is  the  structural  part  of  the  system 


and  includes  depth  and  width  subtyping.  This  relation  is  used  for  both  record  subtyping  and 
method  list  subtyping:  rules  Sub-Record,  Sub-Obj  and  Sub-Method  of  Fig. 


2.17 
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r  t-j;  Ti  <  T2 


Subtype  judgement  (expression  types) 
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(Sub-Method) 
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Figure  2.17:  Subtype  judgements.  The  context  Z  is  omitted  from  the  turnstile  symbol  in  the 
inference  rules,  as  it  does  not  change  in  the  course  of  the  derivation  (i.e.,  the  rules  use  whichever 
context  was  passed  to  the  judgement) 


The  rule  Sub-Record  is  straightforward;  it  simply  uses  the  sub-row  judgement  directly.  The 
rule  Sub-Obj  corresponds  to  Definition  ED  and  uses  both  the  sub-brand  and  sub-row  judge¬ 
ments.  This  rule  specifies  that  an  object  type  Bi(Mi)  is  a  subtype  of  B2(M2)  when  By  is  a  sub¬ 
brand  of  B2  (By  Ex  B2)  and  My  is  a  sub-row  of  M2  (Mi  <  M2). 

For  subtyping  on  method  types,  the  rule  Sub-Method  is  a  straightforward  generalization  of 
function  subtyping:  it  is  contravariant  in  the  argument  position  (the  structural  constraints  on 
the  receiver)  and  covariant  in  the  result. 


The  language  also  includes  a  limited  form  of  intersection  types,  a  la  Davies  and  Pfenning 
(i.e.,  no  distributivity  rule);  the  rules  for  subtyping  intersection  types  are  borrowed  from  their 
work  I  Davies  and  Pfenning||20oo] . 


Aside  from  Sub-Requires,  which  will  be  described  in  Sect, 
rules  are  standard. 


3-7, 


the  remaining  subtyping 
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Typechecking  Programs 


2.22 


2.19 


Full  typing  rules  for  typechecking  programs  and  expressions  appear  in  Figs.  [2.18]  and 
spectively.  Auxiliary  judgements  for  typechecking  programs  are  in  Figures 
auxiliary  judgements  appear  in 


and 


2.21 


2.20 


re- 


other 


There  are  two  typing  rules  for  checking  programs;  these  appear  in  Fig.  2.18  When  type¬ 
checking  a  program,  the  type  information  corresponding  to  each  contained  declaration  is  added 
to  the  main  context  Z,  which  is  used  to  typecheck  subsequent  declarations. 

For  checking  a  brand  or  external  method  declaration,  the  rule  Tp-Decl-Ok  is  used.  This 
first  uses  the  auxiliary  judgement  decl :  decl-type  to  extract  the  declaration’s  declared  type.  Next, 
premise  (2)  checks  that  the  declaration  name  (either  brand  or  external  method)  does  not  already 
exist  in  the  program  context  Z.  Premise  (3)  typechecks  the  types  in  the  declaration  under  its 
declared  context  Zq,  using  the  decl-type  ok  judgement  described  below.  The  method  bodies  in 
the  declaration  (either  internal  or  external  methods)  are  next  typechecked  under  Hq,  decl-type 
(to  allow  recursive  methods)  using  the  body-okjudgement  (also  described  below). 

Here,  it  is  of  key  importance  that  declarations  and  method  bodies  are  typechecked  under 
Zo  rather  than  Z,  as  otherwise  it  would  be  very  difficult  to  prove  that  typechecking  is  modular. 
(The  details  of  the  modularity  proof  are  described  in  Sect. 


3.7.3 


The  next  check,  premise  (5),  ensures  that  the  main  context  contains  at  least  all  of  the  decla¬ 
rations  assumed  by  the  declaration  decl.  Here,  we  use  ordinary  set  inclusion.^®  Finally,  the  rest 
of  the  program  is  typechecked  under  Z  extended  with  the  new  declaration  type. 


Brand  declarations.  The  rule  Tp-Brand-Decl  (Fig.  2.19I  ensures  that  a  brand  declaration  B 
is  well-formed.  First,  we  check  that  the  inheritance  structure  of  B  is  correct,  using  the  inherit- 
okauxiliary  judgement  (Fig.  2.2o|,  which  is  described  in  Sect. 


3-7 


Premise  (2)  of  Tp-Brand-Decl  creates  a  new  context  extended  with  the  current  declaration, 
and  premise  (3)  checks  that  newly  defined  brand  contains  at  least  the  fields  of  the  supertype 
(possibly  with  refined  types),  under  this  new  context.^® 

Finally,  premise  (4)  checks  that  there  are  no  duplicate  internal  methods  in  B  and  premise 
(5)  checks  that  each  method  is  a  valid  override  of  the  same  method  in  superclasses,  should  such 
a  method  exists.  This  last  premise  uses  the  override-okjudgement  in  Fig.  2.20  The  rule  for 


method  overriding  is  a  straightforward  generalization  of  that  of  Featherweight  Java;  the  over¬ 
riding  method  type  p  must  be  a  subtype  of  each  of  p/,  the  types  of  the  super-brand  methods 
being  overridden  (if  such  methods  exist).  This  rule  uses  the  mtype  auxiliary  judgement,  which 


^®Note  that  it  would  not  be  sound  to  take  into  account  some  form  of  subtyping  on  the  declarations  con¬ 
tained  in  Z  to  perform  this  check.  This  is  because  the  program  may  make  either  covariant  or  contravariant 
uses  of  the  declarations  within  Z.  For  instance,  when  making  method  calls  on  an  object  of  a  particular  class  C, 
it  would  be  sound  to  substitute  some  C'  where  C  C'  for  the  purpose  of  typechecking;  i.e.,  this  is  a  covariant 
use  of  C.  In  contrast,  when  extending  a  class,  this  corresponds  to  a  contravariant  usage.  Since  the  type  of  us¬ 
age  of  each  declaration  is  not  specified  when  declaring  Zq,  we  must  assume  either  covariant  or  contravariant 
uses  may  occur;  therefore  the  subset  relation  must  be  invariant. 

^®As  a  consequence,  if  the  field  type  is  a  record,  sub-brands  must  list  all  the  labels  of  the  parent  (and  may 
therefore  access  them).  Aside  from  simplifying  the  calculus,  this  sidesteps  issues  of  variable  shadowing  while 
allowing  subtypes  to  refine  the  type  of  a  particular  label. 
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21  2  22 


def 
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method  B  .q{q  CdM,) :  Xi  =  e,-  :  method  B  .q[Ci.q'  Mi  =>  T; 
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Figure  2.18:  Typechecking  programs 

looks  up  the  type  of  the  method  (internal  or  external)  defined  or  inherited  in  the  specified  brand. 
{mtype  appears  in  Fig. 


2.22 


and  is  described  in  a  subsection  below.) 


For  typechecking  internal  method  bodies,  the  rule  Brand-Decl-Body  is  used,  which  checks 
that  each  method  body  has  the  correct  type,  when  the  special  variables  this  and  fields  are  bound 
to  the  appropriate  types.  Note  that  here  the  method’s  structural  constraints  M,-  are  added  to  the 
brand’s  nominal  type  B  by  specifying  the  type  B[Mi)  for  the  this  variable.  Any  brand  methods 
(internal  or  external)  can  still  be  accessed  by  using  a  qualified  name,  in  the  case  that  a  method 
name  in  the  structural  constraint  conflicts  with  an  existing  method  name. 


External  method  declarations.  The  rule  Tp-Ext-Method  (Fig.  2.19 1  checks  external 


method  definitions.  Premise  (2)  ensures  that  there  are  no  duplicate  external  method  defini¬ 
tions  (i.e.,  more  than  one  method  defined  for  the  same  brand  C).  Premise  (4)  enforces  condition 
£2:  an  external  method  may  not  override  an  internal  method.  The  B.q  internal  auxiliary  judge¬ 
ment  is  used  here  (Fig.|2.2oll;  this  simply  searches  for  a  method  q  that  is  either  defined  internally 
in  B  or  is  inherited.  Finally,  as  in  the  rule  for  brand  declarations,  premise  (6)  ensures  that  each 
external  method  definition  is  a  valid  override  of  other  (external)  methods,  using  the  override- 
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2  I-  decl-type  ok 

(Tp-Brand-Decl) 

®  Hx  B  extends  C  requires  D  inherit-ok 
®  Z'  =  2,  brand  B[r]q-.  p)  extends  C  requires  D  ®  Hj;/  t  <  fieldTypej. (C) 

®  q  distinct  ®  B.qTp  override-ok 

2  I-  brand  B[r;qTp)  extends  C  requires  D  ok 

(Tp-Ext-Method) 

®  Object  ®  C  distinct  ®  Ci^^B  (Vr€l..n) 

®  If  X  C.q  internal  ®  2'  =  2,  method  B  .q[C.q  ■  p)  ®  C.q  ■  p  override-ok 

2  I-  method  B  .q[C.q  ■  p)  ok 

2  I-  decl  body-ok 

(Brand-Decl-Body) 

fieldTypej.(B>)  =  this :  B(Mi), fields  :  cr  a  i-zS/'f; 

brand  B{a',qi  B[Mi)  ■  ti  =  et  extends  C  requires  D  body-ok 

(Ext-Method-Body) 

this  :  CiiMi)  i-x  Bi  ■■  Ti  (V i  €  l..n] 

2  I-  method  B  .q{q  Q (M,) :  t,-  =  ei  body-ok 
Figure  2.19:  Typechecking  brand  and  method  declarations 


okjudgement. 

For  typechecking  external  method  bodies,  rule  Ext-Method-Body  applies,  which  is  similar 
to  the  rule  for  typechecking  internal  methods.  The  sole  difference  is  that  the  fields  variable  is 
not  bound  in  T  and  therefore  cannot  be  accessed  by  the  method  body,  which  effectively  enforces 
a  form  of  information  hiding. 


Expressions.  Typechecking  expressions  (Tp-Expr-Ok)  simply  defers  to  the  judgement  for 
typechecking  expressions  (Fig.|2.2i|.  Most  of  the  rules  are  standard;  the  exceptions  are  Tp-New- 
Obj,  Tp-With,  Tp-Invoke-Struct,  Tp-Invoke-Nom,  and  Tp-Invoke-Super.  The  first  four  are 
described  here;  the  last  regards  multiple  inheritance  and  is  described  in  Sect. 


3-7 


The  rule  Tp-New-Obj  checks  the  correctness  of  the  object  creation  expression.  First,  we 
check  that  the  provided  expression  conforms  to  the  field  type  of  the  brand.  Next,  we  check 
that  the  simple  names  provided  in  the  mapping  are  distinct,  then  look  up  the  method  type  pi 
of  each  qualified  name  (using  the  mfype  judgement,  described  below).  The  resulting  type  has  a 
structural  component  that  maps  each  n,-  to  the  corresponding  p,. 
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Hj;  B.q  ■■  p  override-ok 


B  extends  Cl,..., C„  €  Z  mtype-^{q,Ci)  =  p'^  implies  p  <  p'-  (Vi€l..n) 

Hj;  B.q  ■■  p  override-ok 


\-z  B  inherit-ok 


(Tp-Inherit) 

®C€Z  @DeZ  @  D,  ^  C  (VieL.m) 

®  V  z,  j.  i  *  j.  W'.  Ci  Ei  D'  and  Cj  Ei  D'  {D'  ^  Object) 

®  C(  requires  Be  Z  implies  3A:.  Ei  B  or  Ei  £  (Vzel..n) 
®  £) 

i  requires  B' e  Z  implies  3fc.  Cjt  E^  B' or  Djt  Ex  B'  (Vz'€l..m) 
®  V  i,j.  yq.  mtype^iq,  Ci)  =  p  and  mtypej_{q,  Cj)  =  p'  implies  i  =  j 
Hx  B  extends  Cl,..., C„  requires  Di,...,Dm  e  2  inherit-ok 


Hx  B.^  internal 

(Internal-Inh) 

(Internal-Base)  brand  B(t;Q)  extends  Ce  Z  q€Q 

brand  B{r;...,q'  p,...)  eZ  3 A:.  C^.^ internal 

Hx  B.^  internal  i-x  B.^  internal 


Figure  2.20:  Auxiliary  judgements  for  typechecking  programs 


The  mtype  auxiliary  judgement  (defined  in  Fig.  2.22 1  looks  up  the  type  of  a  qualified  name 
defined  for  a  particular  brand  B.  The  judgement  first  checks  for  internal  methods;  if  one  does 
not  exist,  the  second  rule  searches  for  an  external  definition.  If  neither  of  these  cases  applies, 
we  perform  a  lookup  using  some  super-brand  of  B. 


The  next  rule,  Tp-With,  performs  an  operation  similar  to  that  of  Tp-New-Obj.  The  names 
in  the  specified  map  must  not  be  contained  in  the  expression’s  structural  type  (n  ^  M)  and  must 
be  distinct.  Then  mtype  is  used  to  lookup  the  types  of  the  corresponding  qualified  names.  There 
is  one  difference  between  Tp-With  and  Tp-New-Obj,  involving  required  brands  (premises  2  and 


5).  This  difference  is  described  further  in  Sect.  3.7 


It  should  be  noted  that  the  subsumption  rule  can  always  be  used  to  “forget”  methods  in  an 
object’s  structural  type,  so  it  is  possible  add  a  simple  name  mapping  n^q  that  already  existed 
in  the  object’s  map.  That  is,  the  situation  depicted  in  Fig.  2.23  can  occur.  Since  the  subsumption 


rule  allows  the  typechecker  to  “forget”  that  ei  has  method  n,  the  "ei  with  ...”  expression  is  still 
well-typed.  At  runtime,  the  new  mapping  replaces  the  old  one. 


Typechecking  method  invocations  (rules  Tp-Invoke-Struct  and  Tp-Invoke-Nom)  is  fairly 
straightforward,  as  the  body  of  the  method  was  already  checked  when  the  method  was  declared. 
When  invoking  a  method  with  a  simple  name  (structural  method  invocation),  we  ensure  that  the 
method  n  exists  in  the  structural  part  of  the  expression’s  type  (M)  and  has  type  N^t.  Finally,  M 
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r  1-2  e-T 


(Tp-Var) 

x-.reT  (Tp-Unit) 

r  H  x:  T  r  I-  0  :  unit 

(Tp-Subs) 

ri-e:^  i-z  cr<T 
T  i-e’-T 


(Tp-Fun) 

r,  x:  Ti  I-  e:  T2 

r  i-Ax;Ti.e:Ti  ^T2 

(Tp-New-Record) 
T  he'-T 

r  I-  ie  =  e] :  {TTr} 


(Tp-App) 

ri-ei:Ti^T2  ri-e2:ri 

r  I-  ei  62 :  ^2 

(Tp-Proj) 

TheJk'T^k 


(Tp-New-Obj) 

B  requires  •  e  Z  fieldTypej.{5)  =  t  F  i-  e :  t 
n  distinct  mtype^  [q,  B) :  p 

r  \-  B(e;n^  q)  ■  B{n  ■  p) 

(Tp-Invoke-Struct)  (Tp-Invoke-Nom) 

T^e-.B{M)  V^e:B{M) 

n-  N^t  e  M  M<  N  mtype^  iq,B)  ■■  N  ^  t 

r  I-  e.n :  T  r  I-  6.^:  T 


(Tp-With) 

T\-e-B[M)  5  requires  DeZ 

n€  M  n  distinct 

3Ce{B,  D  }.mtype^{qi,C)-- Pi  {\/rel..n) 
The  with  rii  ^  q^  :  B{M,  ni :  pi 

(Tp-Invoke-Super) 

V\-e-B{M)  5  requires  CeZ 

M<N  mtype^{q,C)  ■  N ^  T  M<N 

r  h  e.C.super.^:  T 


(Tp-Fold)  (Tp-Uneold) 

Y  \-e'[pX.TlX]T  Y\-e'pX.T 

r  i-fold^x.Te:pX.T  r  Hunfold^x.re:  [pX.T/X]T 


Figure  2.21:  Typechecking  expressions.  The  context  Z  is  omitted  from  the  turnstile  symbol 
in  the  inference  rules,  as  it  does  not  change  in  the  course  of  the  derivation  (i.e.,  the  rules  use 
whichever  context  was  passed  to  the  judgement) 

must  be  a  structural  subtype  of  n’s  structural  constraint  (M  <  N).  The  entire  expression  therefore 
has  type  t. 

For  invoking  a  method  with  a  qualified  name  (Tp-Invoke-Nom),  the  difference  is  that  the 
method  type  is  not  looked  up  within  M,  but  rather  on  the  brand  B  using  mtype.  As  before,  the 
structural  constraints  must  be  satisfied  (M  <  N). 


2.5.2  Dynamic  Semantics 

The  evaluation  judgements  for  programs  and  expressions  appear  in  Figures  [2.24I  and [2. 25]  re¬ 


spectively.  Auxiliary  judgements  for  method  lookup  are  in  Fig.  2.26] 


In  evaluating  programs  (Fig.  2.24I1,  the  interesting  rules  are  E-Brand-Decl  and  E-Ext-Decl, 
which  evaluate  brand  definitions  and  external  method  definitions,  respectively.  To  evaluate  a 
brand  definition,  the  method  definitions  are  reduced  to  just  the  method  name  and  body;  the 
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mtype^  [q,  B)  =  p 

(MType-Inh) 

(MType-Ext) 

brand  B(t;  Q]  extends  Cel 

(MType-Base) 

brand  B[t;Q)  e  1 

q€Q  extDef^  [q,  B)  =  p' 

brand  B{T;...,q-  p,...)  el. 

extDef^  iq,  B]  =  p 

3k.  mtype^iq.Ck)  =  p 

mtype^iq,B]  =  p 

mtype^  iq,  B)  =  p 

mtype^iq,B)  =  p 

extDef^  {q,B)  =  q.  p 

method  C.q[. . . , B.q ■  p,.. 
extDef^iq,B)  =  p 

)e2 

Figure  2.22:  Auxiliary  functions  for  typechecking  expressions 


Program 

Types 

Values 

brand  B(-:  :()=:>  ti, ^2  •  0  ^  T2)  e  Z 

ei-B{-,n^qd 

ei-Bi-,n^qd 

xi  =  ei.q^ 

Xi  :Ti 

Xi  1 - ^  Pi 

yi  =  ei-n 

yi^ri 

yi  ' — ^  Pi 

€2  -  Cl  with  n^q2 

B(n:0^Ti)<B0 

ei-.B[n:i)^Ti) 

e2-Bin:Q^T2) 

62  =  61  with  n^q2 

X2  =  62  ■?2 

X2-T2 

X2  < - ^  V2 

y2  =  e2.n 

y2-T2 

y2  1 - ^  V2 

B{-,n 


^2) 


Figure  2.23:  Example:  typechecking  new  object  and  “with”  expressions 


rest  of  the  program  is  evaluated  with  the  extended  context.  Similarly,  E-Ext-Decl  updates  the 
context  with  new  external  method  definitions,  then  evaluates  the  rest  of  the  program  with  the 
new  context.  In  both  of  these  rules,  method  declarations  are  evaluated  by  discarding  all  type 
information,  leaving  just  the  method  name  and  body. 

For  evaluating  expressions,  the  rules  are  are  standard  (or  are  congruence  rules)  except  for 
E-Invoke-Val,  E-Super-Invk-Val  (which  will  be  described  in  Sect.  [3]^,  and  E-With-Val. 

E-Invoke-Val  uses  the  auxiliary  judgement  mbody^im,B,  n^q).  This  latter  judgement, 
which  I  describe  below,  finds  the  appropriate  method  body  e  for  a  method  m.  The  object  is  then 
substituted  for  this  and  its  fields  are  substituted  for  fields  within  e. 


The  mbody  judgement  (Fig.  2.26|  is  itself  straightforward;  if  we  are  performing  qualified 
method  lookup,  the  lookup  judgement  is  called  directly,  otherwise  the  appropriate  qualified 
name  is  found  within  the  object’s  map. 
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Evaluating  programs 

pW^p’lA' 

(E-Brand-Decl) 

m-decl  I — ^  B.q  =  e 

p  I  A,  B[q=  e)  extends  C 

(E-Expr) 

e  I — e' 

Zo  method  B  .q{m-decl)  m  p  \  IS.  ^ — >■  p  |  A,  method  ^(C.^=  e)  Zi>e|Ai  >  e' 

Auxiliary  judgement 

m-decl  I — >■  q  =  e 

q  B{M)\r  =  e  i — ^  B.q=e 


Z  0  brand  B(t:  m-decl)  extends  C  requires  D  in  p  |  A 
(E-Ext-Decl) 

m-decl  I — ^  C.q  =  e 


Figure  2.24:  Evaluation  and  auxiliary  judgement  for  programs 


The  /ooArup  judgement,  in  turn,  is  similar  to  mbody  in  Featherweight  Java,  with  the  exception 
that  the  rule  Lookup-Ext  is  added  (for  external  method  lookup).  The  judgement  first  looks  for 
methods  defined  within  the  brand  itself  (Lookup-Base).  If  such  a  method  does  not  exist,  an 
exactly  matching  external  method  (Lookup-Ext)  is  searched.  If  neither  of  these  cases  apply,  we 
perform  lookup  on  the  unique  super-brand  of  B  for  which  lookup  is  defined. 

Returning  to  expression  evaluation,  the  rule  E-With-Val  evaluates  a  “with”  expression  by 
creating  a  new  object  with  a  combination  of  the  new  and  old  mappings.  Here,  the  merge  function 


is  used  (Fig.  [2.26  ,  which  retains  only  only  those  old  mappings  Ua  ^  q^  that  do  not  exist  in  the 
new  map  nt,  ^  q^,.  We  saw  an  example  of  this  in  Fig.  2.23  the  expression  62  evaluated  to  an 


object  containing  only  the  new  mapping  for  n  (i.e.,  dropping  the  mapping  n  ^  q). 


2.5.3  Adding  Polymorphism 


The  Unity  formal  system  (as  presented  in  this  chapter)  does  not  contain  parametric  polymor¬ 
phism.  This  omission  is  intentional  and  is  to  simplify  the  formal  system.  Upon  adding  polymor¬ 
phism  to  an  earlier  version  of  the  calculus  [Malayeri  and  Aldrich|20o8a|b|,  I  discovered  that  it 
was  orthogonal  to  Unity’s  novel  features. 

This  calculus,  Unitya  adds  type  variables  to  brand  declarations  and  includes  polymorphic 
functions  (defined  the  standard  way,  with  the  A  notation) .  The  calculus  adds  an  additional  judge¬ 
ment  that  checks  that  types  are  well-formed  (e.g.,  a  type  instantiation  must  have  the  same  arity 
as  that  of  its  corresponding  type  constructor).  Unitya  was  a  straightforward  extension  of  Unity, 
as  there  was  not  an  interesting  interaction  between  parametric  polymorphism  and  either  struc¬ 
tural  subtyping  or  external  dispatch. 
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e  I — e' 

Computation 

(E-App-Abs)  (E-Proj-Val) 

[Ax-.t.  e]  V  I — [vlx]  e  {£i  =  vi  1 — ^a  Vk 

(E-Invoke-Val) 

3  unique  e.  mbody^  [m,B,n<^  q)  =  e 
B{v,  n  ^  q).m  1 — ^a  {B[v;  n  ’—>■  ^)/this,  p/fields}  e 

(E-Super-Invk-Val) 

3  unique  D.  super ^[B  as  C)  =  D  3  unique  e.  lookup i^{q,D)  =  e 
B{v;  n  ^  ^i.C.super.ij'  1 — ^a  {B[v;  n  ^  ij'j/this,  y/fields}  e 

(E-With-Val)  (E-Unfold-Eold) 


B{v;na-^qa]  with  rib^q^  1 — ^a  B{v;  mergeirib'^  qi„nc 


unfold^  (foldo-  v) 


V 


Congruence 

(E-Appi) 


ei 


(E-ApP2) 
ez  I — ^A  Co 


(E-Record) 


CiCz  I — ^A  ^162  I — ^A  Vie'2  [(i  =  Vi,...,£k-1  =  Vk-\,£k  =  Sk,.--)  ' — {...,£k  = 


(E-Proj) 


(E-Obj) 


^A  e 


e.£ 


e'.£ 


>A  e 


(E-Invoke) 
e  I — ^A  e' 


Bie;  n.’^q)  1 — >-a  Bie';  rf^q) 


e.m 


>A  e  .m 


(E-Super-Invk) 


^A  e 


e.B.super.^  1 — ^a  e^S.super.^ 


(E-With) 


^A  e 


e  with  n.’^q  1 — ^a  with  n-^q 


(E-Eold) 


^A  e 


foldt  e  I 


foldr  e' 


(E-Unfold) 


^A  e 


unfold^  e 


unfoldr  e' 


Figure  2.25:  Evaluation  judgement  for  expressions 
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mbody/^[m,B)  =  e 


(MBody-Qual) 

lookupi^  iq,  B)  =  eo 
mbody^  [q,  B,n<^q)  =  eo 


(MBody-Simple) 

lookup;^  iq,  B]  =  eo 

mbody^[n,B,  (...,n^q,...)]  =  eo 


lookup^  [q,  B)  =  e 


(Lookup-Base) 

B{...,q=  e, ...)  extends  Ce  A 

lookup [q,  B]  =  e 


(Lookup-Ext) 

Biq=  e)  extends  C  e  A 
method  q{..., B.q  =  e, . . . )  e  A 

lookup^  [q,  B]  =  e 


(Lookup-Inh) 

B{q=  e)  extends  C e  A  qtq 

method  q[D.q  =  e)  €  A  implies  BtD  3  unique  k.  lookup i^[q,  C^)  =  e 

lookup^  iq,  B)  =  e 


super [B  as  C]  =  D 

(Super-Base) 

(Super-Inh) 

3L>'  Ea  C.  B  extends  D'  e  A  B  extends  £  e  A 

B  extends  D  €  A  D  Ea  C 

3D.  super as  C]  =  D 

super ^{B  as  C)  =  D 

super ^{B  as  C)  =  D 

merge{nb  ^  qi,,  na^qa]  =  n^q 


merge{n},  qi,,  na  ^  qa)  =  ^  ^  ^  I  n^q^Ua’-^qa  and  nt  Ub} 


Figure  2.26:  Auxiliary  judgements  for  expression  evaluation 


2.6  Related  Work 


Here,  using  the  stream  examples  from  Sect.  |2.2[  Unity  is  compared  to  both  mainstream  lan¬ 
guages  and  to  closely  related  research  languages.  Other  related  work  is  presented  in  Sectionsjij^ 
and  5.3  Note  that  for  the  purposes  of  this  comparison,  I  assume  that  StringStream  was  defined 


as  a  sub-brand  of  AbstractReader  (rather  than  AbstractWriter  as  in  Fig.  2.4 1. 


Java-like  languages.  In  Java-like  languages,  it  would  be  awkward  to  implement  many  aspects 
of  the  examples.  First,  we  would  have  to  define  a  number  of  interfaces  in  order  to  obtain  the 

(P- 


subtyping  relationships  displayed  in  Fig. 
in  Fig. 


2.6 


_  ).[^.  Oi 

2.27}  compare  to  the  Unity  hierarchy  in  Fig.  [2.28  In  particular,  I  have  defined  interfaces 


One  plausible  Java  hierarchy  is  displayed 
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Reader,  ResetableReader,  Seekable,  SeekableReader,  and  so  on.  In  a  real  system,  the  situation 
could  be  even  worse:  here  I  have  included  the  method  mark  in  the  ResetableReader  interface,  but 
some  streams  may  support  reset  but  not  mark  (this  is  true  of  the  streams  in  java. io. Reader,  for 
instance). 

Additionally,  since  Java  lacks  intersection  types,  we  must  manually  create  compound  in¬ 
terfaces,  such  as  WriteableSeekable  and  ReadableWritableSeekable.  Further,  we  must  take  care  to 
use  these  interfaces  rather  than  the  interfaces  they  extend;  for  instance,  StringStream  implements 
ReadableWriteableSeekable  rather  than  Reader,  Writer,  and  Seekable. 

There  are  additional  issues  with  the  Java  implementation.  If  the  type  SomeOtherReader  is 
defined  in  a  library  (independently  of  the  Reader,  etc.,  abstractions),  we  cannot  write  a  findString 
method  that  will  accept  either  an  AbstractReader  or  SomeOtherReader  as  an  argument.  This 
is  because  of  the  lack  of  retroactive  interface  implementation:  changing  SomeOtherReader  to 
implement  Reader  requires  access  to  its  source. 


One  possible  workaround  is  to  use  instanceof  tests: 

boolean  findString(Object  o)  { 

if  (o  instanceof  AbstractReader) 

.  .  .  // can  call ‘read’, ‘skip’, ‘mark’ 
else  if  (o  instanceof  SomeOtherReader) 

.  .  .  // same  code  as  above 
else 

throw  new  UnsupportedOperationException("Unknown  reader"); 


Aside  from  the  potential  for  runtime  errors,  there  are  both  code  duplication  and  extensibility 
problems.  That  is,  if  a  new  “reader”  type  is  added  (where  an  existing  branch  does  not  apply), 
programmers  must  remember  to  add  a  new  branch  to  the  conditional.  I  would  like  to  empha¬ 
size  that  this  is  not  a  hypothetical  problem:  Sect.  [4. 5 .3] provides  examples  of  real  code  with  this 
pattern. 

Another  workaround  is  to  use  reflection,  but  this  solution  would  forgo  static  type  safety. 
(One  advantage  of  reflection  over  instanceof  tests,  however,  is  that  the  code  is  more  extensible.) 
We  will  also  encounter  a  problem  when  trying  to  implement  the  parse  method  in  Fig. 


2.2 


(p.[^.  The  Visitor  design  pattern  ([Gamma  et  al.||i9^|)  is  not  appropriate  here,  since  the  need 


for  it  must  be  anticipated  and  it  also  makes  class  extensibility  very  difficult  [Clifton  et  al. 


2000 


A  workaround  is  to  again  use  instanceof  tests,  as  below: 

AST  parse(ResetableReader  reader)  { 

if  (reader  instanceof  CharArrayReader) 

. . .  // parse  using  ‘seek’  method 

else 

. . .  //  use  ‘mark’  and  ‘reset’ 


Again  there  is  an  extensibility  problem:  if  a  new  kind  of  ResetableReader  is  defined,  the  only 
means  of  extension  is  to  update  this  method  |Malayeri|2009c| . 
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Figure  2.27:  The  same  example  implemented  in  Java.  Classes  that  correspond  to  the  Unity 
brands  are  shaded  gray.  Dashed  lines  indicate  the  implements  relationship  and  solid  lines  in¬ 
dicate  extends. 


Figure  2.28:  The  streams  example  as  implemented  in  Unity.  Depicted  here  are  the  brands  that 
must  be  defined  in  order  to  obtain  the  desired  subtyping  relationships. 


Since  seekAndWrite  and  readAndWrite  (Fig. 
can  be  implemented  in  Java  using  a  static 


2.4 


21 1  are  not  external  methods,  they 

and 


method  that  takes  a  WriteableSeekable 
ReadableWriteableSeekable  as  an  argument.  Of  course,  we  will  encounter  problems  when  us¬ 
ing  classes  that  do  not  implement  those  interfaces  (as  we  saw  with  the  findString  method). 

Finally,  to  implement  the  code  in  Fig.|2.5|(p.[^,  a  common  solution  is  to  use  the  Decorator 
pattern  to  implement  the  newline  method.  That  is,  we  would  define  a  class  WriterDecorator  with 
a  field  of  type  writer  that  provided  an  implementation  of  newline.  (In  this  example,  newline  does 
not  need  require  access  to  AbstractWriter  methods  for  its  implementation,  but  this  is  not  the  case 
in  general.)  Finally,  EnhancedWriter  would  extend  WriterDecorator  and  provide  an  implementa¬ 
tion  for  writeLine. 

To  use  the  writeLine  code,  the  method  could  not  be  called  directly,  as  in  Unity,  but  rather  the 
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pattern  new  EnhancedWriter(writer).writeLine()  would  have  to  be  used.  Aside  from  the  awk¬ 
wardness  of  this  solution,  there  will  also  be  problems  with  object  identity:  writer  is  not  equal  to 
a  wrapped  writer,  even  though  they  are  semantically  equivalent. 

Overall,  this  example  shows  the  impracticality  and  unwieldiness  of  implementing  the  Unity 
examples  in  a  Java-like  language. 


Intersection  types.  In  a  language  with  nominal  subtyping  and  intersection  types  |  Coppo 
and  Dezani-Ciancaglini  1978}  Coppo  et  al.  1979!  Pottinger  1980  Biichi  and  Weck]i998|, 


some  aspects  of  the  Java  design  would  be  easier  to  express,  but  the  same  fundamental  prob¬ 
lems  would  remain.  The  benefit  of  intersection  types  is  that  the  interfaces  SeekableReader, 
ReadableWriteableSeekable,  and  WriteableSeekable  would  not  have  to  be  defined,  since  they  are 
combinations  of  other  interfaces. 

However,  the  other  aspects  of  the  design  would  be  the  same  as  the  Java  design.  In  particular, 
instanceof  tests  would  be  necessary  to  implement  findString  and  parse,  and  newline  would  be 
implemented  using  a  decorator. 

Of  course,  intersection  types  are  a  very  useful  language  feature  in  their  own  right  and  have 
been  included  in  the  Unity  design  (see  Sect. 


Functional  programming  languages.  If  we  attempt  to  express  the  examples  of  Figures  [2^ 
and  I2.3I  (pages  [1^  and  |2.2|l  in  an  ML-like  language,  we  would  also  encounter  difficulties. 


2.2 


In  this  case,  it  is  due  to  the  lack  of  support  for  typechecking  extensible  datatypes.  In  particular, 
there  is  no  explicit  language  support  for  modifying  a  case  analysis  expression  post-hoc — but  this 
is  precisely  what  would  be  needed  to  encode  the  Unity  examples. 

One  approach  for  modeling  an  inheritance  hierarchy  in  ML  is  to  use  datatypes  and  case 
analysis.  Fig.  2.29  shows  such  an  encoding.  Here,  we  define  the  datatype  AbstractReader  with  a 


constructor  corresponding  to  each  concrete  stream  class.  The  values  carried  by  the  constructors 
are  simply  the  internal  representation  of  each  of  the  corresponding  Unity  brands.  For  example, 
the  CharArrayReader  constructor  stores  the  internal  character  array.  Methods  become  functions 
defined  on  AbstractReader,  with  a  case  analysis  to  perform  different  behavior  for  different  types 
of  streams. 

However,  using  ML  datatypes  does  not  give  us  all  the  extensibility  of  Unity  brands.  In  par¬ 
ticular,  ML-like  languages  have  the  following  shortcomings: 

1.  Datatypes  are  closed  to  extension,  unless  exhaustiveness  checking  is  sacrificed;  and 


2.  There  is  no  mechanism  for  adding  new  cases  to  existing  functions  without  modifying 
them  directly. 

Therefore,  to  encode  the  Reader  type  of  Fig.  EH  we  will  use  a  record  of  functions.  This  is 
decidedly  a  more  “object-oriented”  style  of  programming  and  does  create  some  awkwardness 
when  used  in  ML.  The  new  code  is  displayed  in  Fig.|2.3o[ 

Note  that  the  programmer  must  manually  manage  the  creation  of  these  records  of  func¬ 
tions  for  each  subtype  relation  that  is  used.  For  instance,  if  we  had  a  type  EnhancedReader 
that  contained  the  mark  and  reset  methods,  we  would  have  to  create  a  record  to  convert  the 
CharArrayReader  type  to  an  EnhancedReader.  Additionally,  subtype  properties  such  as  transitiv¬ 
ity  must  be  encoded  as  functions  which  must  be  explicitly  called. 
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datatype  AbstractReader  = 

CharArrayReader  of '{'  arr:  char  array '}' 

I  BufferedReader  of '{'  (*  implementation  fields  *) '}' 

I  SimpleReader  of '{'  (*  implementation  fields  *) '}' 

fun  read  (r:  CharArrayReader)  =  ...(*  corresponds  to  method  CharArrayReader. read  *) 
I  read  (r:  BufferedReader)  =  ...(*  corresponds  to  method  BufferedReader.read  *) 

I  read  (r:  SimpleReader)  =...(*  corresponds  to  method  SimpleReader. read  *) 

fun  skip  (r:  CharArrayReader)  (len:  int)  =  .  .  . 

I  skip  (r:  BufferedReader)  (len:  int)  =  . .  . 

I  skip  (r:  SimpleReader)  (len:  int)  =  . .  . 

fun  close  (r:  ...)  =  ..  . 

fun  mark  (r:  CharArrayReader)  =  ...(*  non-exhaustive  match  *) 


Figure  2.29:  Encoding  Fig.  2.1  in  ML  using  datatypes 


Up  until  this  point,  we  have  not  encountered  any  major  obstacles  in  our  ML  translation.  How¬ 
ever,  this  is  no  longer  the  case  if  we  attempt  to  translate  the  code  in  Figures[2^and[2^(pages[i^ 
and[^,  as  this  code  requires  both  brand  extensibility  and  external  dispatch. 

Once  we  have  encoded  objects  as  records  of  functions,  there  is  no  way  to  write  methods 
that  externally  dispatch  on  these  objects;  there  is  no  runtime  tag  associated  with  the  record. 
Accordingly,  with  this  approach,  it  is  not  possible  to  encode  the  parse  method  of  Fig [2^ in  the 
functional  setting.  If  we  were  to  change  our  object  representation  to  add  tags  of  some  sort, 
encoding  other  aspects  of  the  system  would  become  difficult.  For  instance,  it  is  unclear  how  to 
write  internal  methods  that  override  external  methods,  as  in  Fig.  [2^ 

As  far  as  the  author  is  aware,  it  would  be  impossible  to  encode  the  unique  features  of  Unity 
in  ML  (or  current  extensions  thereof)  and  also  maintain  the  same  static  safety  guarantees  pro¬ 
vided  by  Unity. For  example.  Unity  ensures  that  an  internal  version  of  a  method  is  called,  if  it 
is  more  specific  than  an  external  method,  and  also  ensures  that  method-not-found  and  method- 
ambiguous  errors  do  not  occur  at  runtime  (Sect.  3.7.4I1.  Additionally,  it  would  not  be  straight¬ 
forward  to  implement  the  multiple  inheritance  (or  even  single  inheritance)  aspects  of  Unity 
(described  further  in  Chapter[3|  in  such  a  setting. 

I  2004) ,  that  aim  to  com- 


Finally,  while  there  exist  languages  such  as  EML  |  Millstein  et  al. 


2002 


bine  the  strengths  of  functional  and  object-oriented  languages,  these  languages  are  sufficiently 
different  from  ML  that  it  is  not  at  all  obvious  how  structural  subtyping  would  be  integrated  into 
them.  Furthermore,  as  this  dissertation  is  based  upon  the  same  foundations  as  EML,  it  would 


^“Certainly,  it  would  be  possible  to  encode  Unity’s  dynamic  semantics  using  ref-cells  and  records  of  func¬ 
tions,  but  this  would  amount  to  a  dynamically-typed  encoding.  As  described  in  Sect.  EH  maintaining  static 
type  safety  is  an  explicit  goal  of  this  dissertation. 
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datatype  CharArrayReader  =  CharArrayReader  of  {  arr:  char  array } 
datatype  BufferedReader  =  BufferedReader  of  { f*  implementation  fields  *) } 
datatype  SimpleReader  =  SimpleReader  of  { f*  implementation  fields  *) } 

fun  readCharArray(r:  CharArrayReader)  =  .  .  . 
fun  readBuffered(r:  BufferedReader)  =  .  . . 
fun  readSimpleReader(r:  SimpleReader)  =  .  .  . 


type  'a  Reader  =  { read:  'a  unit  char,  skip:  'a  ^  int  ^  int,  close:  'a  unit  ^  unit } 

val  charArrayFns  =  { read  =  readCharArray,  skip  =  skipCharArray,  close  =  closeCharArray } 
val  bufReaderFns  =  { read  =  readBuffered,  skip  =  skipBuffered,  close  =  closeBuffered  } 

fun  findString  (obj:  'a)  (r:  'a  Reader)  (s:  string)  :  int  =  .  .  .  r#read  obj . .  .  (*find  the  string  *) 


findString  charReader  charArrayFns  "bar" 
findString  bufReader  bufReaderFns  "foo" 


(*  add  a  new  type  o/Reader,  plus  conversion  to  Reader  *) 

datatype  SomeOtherReader  =  SomeOtherReader  of  { f*  implementation  fields  *) } 
val  someOtherReaderFns  =  .  . . 

findString  otherReader  someOtherReaderFns  "baz  (*  "findString"  works  on  new  object  *) 


Figure  2.30:  Improved  ML  encoding  of  Fig. 


2.1 


appear  that  integrating  structural  subtyping  into  that  setting  would  pose  the  same  challenges 
that  are  already  addressed  in  this  work. 


Mixins,  traits.  Mixins  jBracha  and  Cook  1990 

Ancona  and  Zucca  1996 

Flatt  et  al. 

1998 

Findler  and  Flatt||i999j|Ancona  et  al.||2003j  Bettini  et  al.||2004 

and  traits  |Ducasse  et  al. 

2006 

Fisher  and  Reppyl2004}  Odersky  and  Zengerj2005|  would  allow  the  code  to  be  structured  some- 

what  differently,  but  the  resulting  design  would  still  lack  the  extensibility  of  the  Unity  solution. 
Though  there  are  differences  between  mixins  and  traits,  these  differences  are  not  relevant  for 
the  comparison  in  this  chapter. 


To  implement  findString,  a  mixin  or  trait  TFindStringUtil  would  be  defined.  This  mixin/trait 
would  declare  the  methods  of  Reader  as  required  members  and  the  findString  method  could 
therefore  use  these  methods  as  in  the  Unity  implementation.  However,  concrete  classes  that  use 
the  mixin/trait  must  still  be  defined:  one  for  each  of  AbstractReader  and  SomeOtherReader.  That 
is,  we  would  have  to  create  a  class  AbstractReaderFindString  that  inherited  from  AbstractReader 
and  mixed  in  TFindStringUtil,  and  similarly  for  SomeOtherReader.  Aside  from  the  awkwardness  of 
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this  design,  the  findString  method  could  not  be  used  directly  on  an  object  of  type  AbstractReader 
(or  SomeOtherReader),  one  of  the  new  subclasses  must  be  used  instead. 

However,  with  mixins  or  traits,  the  implementation  of  writeLine  (Fig,  [a.sf  would  be  more 
elegant  than  that  of  Java.  We  could  define  a  mixin/trait  TWriteLine  that  declared  the  methods 
of  AbstractWriter  and  also  the  newline  method  as  required  members.  We  would  also  define  a 
mixin/trait  TNewLine  with  the  methods  of  AbstractWriter  as  required  members.  Finally,  we  would 
have  to  create  a  concrete  class  EnhancedWriter  that  inherited  from  AbstractWriter  and  also  mixed 
in  TWriteLine  and  TNewLine.  Again  we  would  have  the  problem  that  writeLine  could  only  be  called 
on  instances  of  EnhancedWriter,  rather  than  objects  of  the  existing  types. 

Sections[3.8|and[3.5.4|provide  additional  comparisons  to  mixins  and  traits  in  the  context  of 
the  Unity  multiple  inheritance  features. 


Structural  subH 


/^ping.  Languages  which  support  structural  sub  typing,  such  as  PolyTOIL 


[  Bruce  et  al.  2003 

,  Moby  [ 

Fisher  and  Reppy 

i999|<  O’Caml  [Leroy  et  al.|2004),  Scala  [Odersky 

and  Zengerfaoosl 

Odersky 

2007)  and  Whiteoak  [Gil  and  Maman  20o8|  would  elegantly  express 

all  of  the  desired  subtyping  relationships,  but  these  languages  allow  only  internal  dispatch — that 
is,  all  methods  must  be  defined  inside  the  class  definition.  Therefore,  to  define  a  method  such 


as  parse  (Fig.  2.2 1,  as  in  Java,  some  form  of  instanceof  test  must  be  used. 

Of  the  aforementioned  languages,  only  Scala  allows  a  type  to  have  both  a  nominal  and  struc¬ 
tural  component,  which  is  achieved  using  intersection  types.  However,  Scala  does  not  allow 
defining  recursive  structural  types  (such  as  Writer  in  Fig.  [2^.  Consequently,  Writer  would  have 
to  be  a  nominal  type,  and  we  would  once  again  encounter  the  problems  of  retroactive  interface 
extension. 

Additionally,  these  languages  do  not  allow  structural  constraints  to  be  placed  on  a  method’s 


receiver  (such  as  the  parse  method  in  Fig.  2.2 1.  While  this  is  consistent  with  the  single  dispatch 
semantics  that  gives  special  status  to  a  method’s  receiver,  in  a  external  or  multiple  dispatch  set¬ 
ting,  the  Unity  design  is  more  uniform. 


ML-style  and  first-class  modules.  ML-style  modules  [Milner  et  al.|i997|  use  structural  sig¬ 
nature  matching,  and  as  such  could  be  used  to  encode  the  subtype  polymorphism  aspect  of  a 
structurally- typed  object-oriented  language.  Such  an  encoding  would  not  be  as  expressive  as 
Unity,  however,  as  one  would  need  the  capability  of  dynamically  selecting  among  types  defined 
in  different  modules.  With  ordinary  ML  modules,  this  would  require  a  global  re-write  of  the 
program.  Additionally,  this  encoding  would  likely  require  a  large  degree  of  functorization. 

A  first-class  module  system  (e.g.,  [Dreyer  2005)  [Preyer  et  ak  2003)  Dreyer  and  Rossberg 


20o8|)  would  solve  these  problems,  but  such  designs  do  not  directly  address  the  problems  con¬ 
sidered  in  this  dissertation  (though  they  are  quite  useful  in  their  own  right).  In  particular,  the 
analogue  to  external  dispatch  in  this  setting  is  unclear:  even  first-class  modules  do  not  provide 
a  tagging  (let  alone  sub-tagging)  mechanism,  so  one  would  have  to  fall  back  on  the  datatype 
encoding  from  above,  which  was  shown  to  lack  the  desired  properties. 


Retroactive  interface  extension.  Some  languages,  such  as  JavaGI  jWehr  et  al.  2007)  and 
Cecil  [Chambers  and  the  Cecil  Group||2004|  provide  both  external/multimethod  dispatch  and 
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retroactive  interface  extension.  That  is,  after  a  class  has  been  defined,  new  external  methods 
can  be  defined  for  it,  or  it  can  be  declared  to  extend  a  new  interface,  or  both.  However,  Cecil 
(Chambers  and  the  Cecil  Group[|20^|  requires  whole-program  typechecking.  JavaGI  |Wehr 
et  al.  2007)  performs  some  modular  typechecking,  but  defers  some  type  checks  to  class-load 
time,  even  when  dynamic  classloading  is  not  used. 

In  fact,  there  appears  to  be  a  fundamental  tension  between  retroactive  (nominal)  interface 
extension  and  modular  compilation  and  typechecking.  The  situation  is  exacerbated  with  tagged 
interfaces;  such  a  feature  would  essentially  allow  adding  new  tags  to  existing  objects.  This  poses 
problems  both  for  typechecking  external  methods  and  for  program  reasoning.  The  details  of 
these  problems  are  described  in  Sect.|5.i[ 

One  compromise  is  to  use  expanders,  which  allow  typesafe,  statically-scoped  object  adap¬ 
tation  iWarth  et  al.||2006|.  Using  expanders,  programmers  can  non-invasively  update  existing 
classes  to  add  new  fields  and  methods  and  to  implement  new  interfaces.  The  statically  scoped 
nature  of  expanders  is  particularly  appealing,  as  clients  have  flexible  control  over  the  visibility  of 
the  adapted  classes.  However,  expanders  are  not  as  flexible  as  full  structural  subtyping.  Though 
it  is  possible  to  use  “expander  overriding”  to  extend  existing  expanders,  some  forms  of  post-hoc 
changes  are  still  difficult  with  expanders.  For  instance,  if  one  expander  £1  augments  class  C  with 
method  m,  it  is  not  possible  for  another  expander  £2  to  extend  £1  and  make  C  now  implement 
interface  /  (which  requires  method  m).  Accordingly,  expanders  are  only  a  partial  solution  to  the 
problem  of  retroactive  abstraction. 

Scala  “implicits”  (formerly  called  views),  allow  programmers  to  easily  define  adapters  from 


one  obj  ect  to  another  |  Odersky  2007)  and  are  very  useful  as  a  workaround  for  the  lack  of  retroac¬ 
tive  abstraction  in  Java-like  languages.  Among  other  things,  implicits  allow  programmers  to 
specify  specify  method  renamings.  As  implicits  are  lexically  scoped,  they  are  similar  to  Unity’s 
“using  ...  in”  expression  (Sect.  2.4.3}. 


Type  classes.  Many  aspects  of  the  Unity  examples  can  be  quite  elegantly  encoded  using  type 
classes,  which  provide  a  principled  form  of  ad-hoc  polymorphism  |  Wadler  and  Blott|i989  Hall 
et  al.|i99^.  However,  since  type  classes  have  no  notion  of  subtyping,  the  encoding  would  lack 
some  of  Unity’s  expressiveness. 

can  be  readily  encoded  using  type  classes;  Reader  would  be  defined  as  a  type  class  and 


Fig- 


2.1 


the  programmer  would  provide  “instance”  declarations  to  make  CharArrayReader,  Buffered  Reader 
and  SomeOtherReader  members  of  the  Reader  type  class.  Instance  declarations  can  be  defined 
after  a  type  has  been  defined,  so  in  that  regard  they  provide  a  form  of  retroactive  abstraction. 

The  difference  between  the  type  class  encoding  and  the  Unity  version  is  more  apparent  for 
the  listing  in  Fig.  2.4  StringStream  does  not  have  to  be  declared  as  an  instance  of  the  type  class 
consisting  of  the  seek  method,  for  instance — once  all  the  method  definitions  have  been  pro¬ 
vided,  structural  subtyping  provides  the  necessary  coercions.  Since  type  classes  do  not  provide 
a  hierarchy  of  any  form,  programmers  would  have  to  manually  provide  coercion  functions  to 
convert  from  one  type  class  to  another.  For  example,  suppose  we  have  some  function  /  de¬ 
fined  for  values  of  the  Equality  type  class  (which  contains  an  equals  function).  If  integer  is  a 
member  of  Comparable  (which  has  both  compares  and  equals  functions),  then  one  would  need  a 
comparableToEquality  coercion  to  pass  an  integer  to  /.  Similarly,  while  in  Unity  we  can  define  an 
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forall  MapType,  SetType,  CollectType,  SetIterType,  CollectIterType: 
method  useMap(m:  MapType):  void 

where  signature  entrySet(MapType):  SetType  and 
signature  values  (MapType):  CollectType  and 

SetType  <=  SetBrand  and 
signature  contains  (SetType,  Object):  bool  and 
signature  iterator( SetType):  SetIterType  and 
...  -  additional  Set  methods 

signature  contains(CollectType,  Object):  bool  and 
signature  iterator(CollectType):  CollectIterType  and 
...  —  additional  Collection  methods 

signature  next  (SetIterType):  Object  and 
signature  hasNext(SetlterType):  Object  and 

-  exact  same  lines  as  above 

signature  next  (CollectIterType):  Object  and 
signature  hasNext (CollectIterType):  Object 

{...} 


Figure  2.31:  Translating  the  structural  types  of  Fig. 


2.8 


to  Cecil  “where”  clause  constraints. 


external  method  and  automatically  widen  the  interface  of  the  class  on  which  it  is  defined,  with 
type  classes  we  would  have  to  provide  a  coercion  manually. 

Additionally,  type  classes  do  not  provide  any  form  of  hierarchical  dispatch,  so  an  additional 
language  mechanism  would  be  necessary  for  this  functionality. 


Note  that  type  classes  are  often  implemented  in  a  manner  similar  to  Unity’s  simple-to- 
qualified  map.  In  particular,  if  a  Haskell  function  /  is  defined  for  types  that  are  members  of 
a  particular  type  class  C,  then  /  is  compiled  to  a  function  that  takes  an  additional  argument:  a 
dictionary  implementing  the  methods  of  C  [Hall  et  al.|i996|.  This  dictionary  is  similar  in  flavor 
to  the  Unity  name  map  that  is  carried  along  with  each  object  value. 


Cecil.  Cecil  fully  supports  external  and  multimethod  dispatch 

I  and  can  also  be  used  to  encode  some  structural  subtyping  patterns 
polymorphism  (“where”  clauses).  Cecil’s  powerful,  but  very  complex, 
type  system  can  express  most  of  the  necessary  relationships  in  my  Collections  example,  but  the 
type  constraints  can  be  come  verbose. 


and  the  Cecil  Group  2004 


using  constraint-bounded 


Chambers  1992)  Chambers 


In  particular,  to  translate  the  writeLine  function  (Fig.  2.5 1,  a  programmer  would  use  bounded 
quantification  and  a  “where”  clause  constraint,  the  latter  being  typechecked  via  a  constraint 
solver  [Chambers  and  the  Cecil  Group||2004  Litvinov  2003 1.  That  is,  in  psuedo-code,  the  argu¬ 
ment  to  writeLine  would  have  type: 
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forall  I:  constraint  Iterator  =  —fictional  abbreviation  for  a  where  clause  constraint 

signature  next  (I):  Object  and 
signature  hasNext(I):  bool 

forall  C,  I:  constraint  Collection  = 

signature  contains(C,  Object):  bool  and 
signature  iterator(C):  I  and 
Iterator  [I] 


forall  MapType,  SetType,  CollectType,  SetIterType,  CollectIterType: 
method  useMap(m:  MapType):  void 

where  signature  entrySet(MapType):  SetType  and 
signature  values(MapType):  CollectType  and 

Set  [SetType,  SetIterType]  and  Collection  [CollectType,  CollectIterType] 


Figure  2.32:  A  possible  syntactic  sugar  for  the  Cecil  “where”  clause  constraints  of  Fig. 
Note  that  even  with  this  syntax,  useMap  still  needs  five  type  parameters 


2.31 


forall  T:  method  writeLine(t:  T):  void 

where T  <=  AbstractReader  and  signature  mark(T):  void  and  signature  reset(T):  void 

Here  there  is  not  an  excessive  amount  of  user-specified  constraints,  but  the  problem  is  com¬ 
pounded  when  translating  nested  structural  types  to  “where”  clauses. 


For  example,  to  achieve  the  expressiveness  of  the  Unity  code  in  Fig.  2.8  the  method  useMap 
would  require  5  type  parameters  and  over  16  “where”  constraints.  A  subset  of  these  constraints 
is  shown  in  Fig.  2.31  Note  the  repetition  in  the  constraints  for  the  pair  SetType  and  CollectType 


and  the  pair  SetIterType  and  CollectIterType.  A  distinct  type  parameter  is  needed  for  encoding 
each  nested  structural  type,  since  “where”  clauses  can  only  be  specified  on  type  parameters. 

Of  course,  it  would  be  possible  to  define  syntactic  sugar  to  simplify  the  definition  of  such  a 
method.  For  instance,  the  language  could  provide  constraint  abbreviations,  such  as  those  illus¬ 
trated  in  Fig. 


2.32 


However,  there  is  still  the  overhead  of  having  to  add  a  type  parameters  wherever  a  where 
clause  is  needed.  As  a  consequence,  every  method  call  from  the  point  where  the  type  parameter 
is  instantiated  to  where  the  object  is  finally  used,  must  also  be  parameterized  and  include  the 
constraint.  That  is,  if  we  wish  to  write  a  function  foo  that  calls  useMap,  it  must  either  instantiate 
the  5  type  parameters  or  must  itself  be  parameterized.  This  latter  design  would  be  necessary  for 
maximal  reusability  of  foo.  Essentially,  requiring  the  use  of  parametric  polymorphism  means 
that  everything  must  be  parameterized  “all  the  way  up”  to  the  point  where  actual  parameters 
are  provided. 

Additionally,  since  only  classes  and  methods  may  have  type  parameters,  if  we  wish  use  a 
structural  type  in  the  body  of  a  method,  we  must  added  a  corresponding  type  parameter  to  the 
method. 


2.7.  Conclusion 
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In  contrast,  in  Unity,  structural  types  are  compositional  (allowing  them  to  be  nested  within 
other  types)  and  can  occur  at  any  level  in  the  program  (e.g.,  the  first-class  functions  findString 
and  seekAndWrite). 

It  should  be  noted,  however,  that  parameterization  can  be  used  to  specify  more  precise  types, 
since  a  subtype  may  only  be  substituted  when  explicitly  allowed  by  the  constraint  (i.e.,  type  pa¬ 
rameters  are  invariant  by  default).  By  using  type  parameters,  programmers  may  also  specify  a 


relationship  between  type  parameters,  such  as  with  the  Subject/Observer  design  pattern  |Litvi- 
nov||20o^. 


In  addition,  I  have  developed  a  version  of  Unity  with  polymorphism  fMalayeri  and  Aldrich 


20o8b|  and  it  does  not  appear  that  adding  (ordinary)  bounded  quantification  would  pose  any 


noteworthy  complications.  In  Unity,  additional  type  parameters  would  be  necessary  only  when 
this  extra  precision  is  needed.  Thus,  in  the  context  of  the  features  of  this  chapter,  I  argue  that 
Unity  is  strictly  less  verbose  and  more  expressive  than  the  corresponding  Cecil  encoding. 


2.7  Conclusion 

This  chapter  showed  how  a  combination  of  nominal  and  structural  subtyping  has  a  number  of 
benefits,  the  most  important  of  which  is  that  it  allows  structural  subtyping  and  external  methods 
to  gracefully  co-exist.  I  also  showed  that  there  is  a  synergy  between  these  two  features:  structural 
subtyping  can  be  used  to  define  an  interface  to  which  brands  can  retroactively  conform.  Then, 
in  the  case  where  additional  code  is  needed  to  provide  this  conformance,  external  methods  can 
be  used.  Thus,  I  have  provided  evidence  that  supports  hypotheses [I| and [Tv] 
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Chapter  3 

Multiple  Inheritance 


1  see  young  men,  my  townsmen,  whose  misfortune  it  is  to  have 
inherited  farms,  houses,  cattle,  barns,  and  farming  tools,  for  these  are 
more  easily  acquired  than  gotten  rid  of 

Henry  David  Thoreau  (Walden) 


This  chapter  details  the  multiple  inheritance  feature  of  Unity,  ^  starting  with  an  overview  of  the 
problem  and  previous  solutions.  I  then  present  the  details  of  the  multiple  inheritance  design 
(including  the  formalization)  and  provide  an  extended  example  and  two  real-world  examples. 


3.1  Overview 


Single  inheritance,  mixins  [Bracha  and  Cook|i99o[  Flatt  et  aL]|i998|,  and  traits  |Ducasse  et  al. 
20o6|  [Odersky  and  Zenger||2005)  each  have  disadvantages:  single  inheritance  restricts  expres¬ 
siveness,  mixins  must  be  linearly  applied,  and  traits  do  not  allow  state.  Multiple  inheritance 
is  one  solution  to  these  problems,  as  it  allows  code  to  be  reused  along  multiple  dimensions. 
Unfortunately  however,  multiple  inheritance  poses  challenges  itself. 

As  mentioned  in  Sect.|i.3|  there  are  two  well-known  problems  with  multiple  inheritance:  (a) 
a  class  can  inherit  multiple  features  with  the  same  name,  and  (b)  a  class  can  have  more  than  one 
path  to  a  given  ancestor,  i.e.,  “diamond  inheritance”  |Sakkinen||i989[  Singh||i994|.  As  the  first 
problem  can  be  solved  by  allowing  renaming  (e.g.,  Eiffel  [Meyer  1997))  or  by  linearizing  the  class 
hierarchy  |Snyder|i986|  Singh|i9^,  I  shall  focus  on  problems  caused  by  diamond  inheritance. 

Recall  that  diamond  inheritance  occurs  when  a  class  (or  brand)  C  inherits  an  ancestor  A 
through  more  than  one  path.  This  is  particularly  problematic  when  A  has  fields — should  C  in¬ 
herit  multiple  copies  of  the  fields  or  just  one?  Virtual  inheritance  in  C++  is  designed  as  one 
solution  for  C  to  inherit  only  one  copy  of  A’s  fields  |  Ellis  and  Stroustru^|i99o[ .  But  with  only 


^The  primary  technical  contributions  of  this  chapter  appear  in  (Malayeri|2009a|b]  [Malayeri  and  Aldrich 


2009a|. 
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one  copy  of  A’s  fields,  object  initializers  are  a  problem:  if  C  transitively  calls  A’s  initializer,  how 
can  we  ensure  that  it  is  called  only  once?  As  we  shall  see  in  Sect.  |3.3|  existing  solutions  either 
lack  expressiveness  or  can  cause  semantic  problems. 

More  importantly,  however,  diamond  inheritances  causes  multiple  inheritance  to  interact 
poorly  with  modular  typechecking  of  external  dispatch.  In  fact,  any  form  of  multiple  inheri¬ 
tance — even  Java-style  multiple  interface  inheritance — suffers  from  this  problem.  Previous  work 
has  not  satisfactorily  addressed  this  problem:  existing  solutions  (described  in  Sect. I3.3I  either 
restrict  expressiveness  or  require  an  exponential  number  of  programmer-supplied  disambiguat¬ 
ing  methods. 

Unity  takes  a  novel  approach  to  this  problem:  while  permitting  multiple  inheritance,  it  for¬ 
bids  inheritance  diamonds.  To  ensure  no  loss  of  expressiveness,  the  notion  of  inheritance  is 
divided  into  two  concepts:  an  inheritance  dependency  (expressed  using  a  requires  clause,  an 
extension  of  a  Scala  construct  |Odersky  and  Zenger  2005I  Odersky|2007|)  and  ordinary  inher¬ 
itance.  Through  examples,  this  chapter  illustrates  how  Unity  retains  the  expressiveness  of  dia¬ 
mond  inheritance:  programs  that  require  diamond  inheritance  can  be  systematically  translated 
to  a  hierarchy  that  uses  a  combination  of  requires  and  no-diamond  multiple  inheritance. 

Additionally,  I  claim  that  a  hierarchy  with  multiple  inheritance  is  conceptually  two  or  more 
separate  hierarchies.  These  hierarchies  represent  different  “dimensions”  of  the  brand  that  is  mul¬ 
tiply  inherited.  Dependencies  between  these  dimensions  are  expressed  using  requires;  Sect.  3 
presents  an  extended  example  of  this  technique. 

The  solution  has  two  advantages:  fields  and  multiple  inheritance  (including  initializers)  can 
gracefully  co-exist,  and  external/multiple  dispatch  and  multiple  inheritance  can  be  combined. 
To  achieve  the  latter,  I  have  made  an  incremental  extension  to  existing  techniques  for  modular 
typechecking  of  external  and  multiple  dispatch.^ 

An  additional  feature  of  the  language  is  a  dynamically-dispatched  super  call,  modelled  after 
trait  super  calls  |Ducasse  et  al.  2006).  When  a  call  is  made  to  A.super./()  on  an  object  with 
dynamic  type  D,  the  call  proceeds  to  /  defined  within  D’s  immediate  super-brand  along  the  A 
path  (i.e.,  some  E  where  D  extends  E  and  E  E  A).  The  brand  A  must  be  specified  because  D  may 
have  more  than  one  parent.  With  dynamically-dispatched  super  calls  and  requires.  Unity  attains 
the  expressiveness  of  traits  while  still  allowing  brands  to  inherit  state. ^ 


3.2  The  Problem 


To  start  with,  diamond  inheritance  raises  a  question  of  semantics:  should  class  (or  brand)  C 
with  a  repeated  ancestor  A  have  two  copies  of  A’s  instance  variables  or  just  one — i.e.,  do  we 
wish  to  have  tree  or  graph  |  Carre  and  Geib  1990)  inheritance  semantics?  As  the  former  may 
be  modelled  using  composition  and  (method  call)  forwarding,  the  latter  is  the  desirable  seman¬ 
tics,  a  semantics  that  is  supported  by  Scala,  Eiffel,  and  C++  virtual  inheritance  |Odersky|2007 


^Without  loss  of  generality,  recall  that  my  formal  system  includes  external  methods  rather  than  full  mul¬ 
timethods;  multimethods  can  be  encoded  using  external  methods  (Sect. 


2.4.2 1. 


^It  would  also  be  possible  to  add  additional  features  present  in  traits,  such  as  the  “exclude”  and  “alias” 
operators.  These  features  will  not  be  discussed  further  in  this  dissertation,  as  they  are  orthogonal  to  the 
problems  on  which  I  have  focused. 


3.2.  The  Problem 
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Figure  3.1:  Stream  classes  in  an  inheritance  diamond.  Italicized  class  names  indicate  abstract 
classes. 


an 


Meyer  1997I  Ellis  and  Stroustrup  1990 1.  Unity  provides  only  graph  inheritance  semantics 
intentional  design  choice. 

Next,  diamond  inheritance  leads  to  (at  least)  two  major  problems  that  have  not  been  ad¬ 
equately  solved:  (1)  determining  how  and  when  the  superclass  constructor/initializer  should 
be  called  |Snyder|i986|  Singh|i994|,  and  (2)  how  to  ensure  non-ambiguity  of  multimethods  in 


a  modular  fashion  [Millstein  and  Chambers||2002|  Frost  and  Millstein||20o6}  Allen  et  ^|2007|. 
Note  that  the  first  problem  only  arises  with  graph  inheritance  semantics,  while  the  second  oc¬ 
curs  in  either  semantics  (tree  or  graph). 


Object  Initialization 

To  illustrate  the  first  problem,  consider  Figure  |3.i|  which  shows  a  class  hierarchy  containing 
a  diamond.  Suppose  that  the  Stream  superclass  has  a  constructor  taking  an  integer,  to  set  the 
size  of  a  buffer.  InputStream  and  OutputStream  call  this  constructor  with  different  values  (1024 
and  2048,  respectively).  But,  when  creating  an  InputOutputStream,  with  which  value  should  the 
Stream  constructor  be  called?  Moreover,  InputStream  and  OutputStream  could  even  call  different 
constructors  (with  different  parameter  types),  making  the  situation  even  more  uncertain. 


Modular  Multiple  Dispatch 

The  second  problem  regards  multiple  dispatch,  which  I  and  others  believe  is  more  natural  and 
expressive  than  single  dispatch  |Chambers||i992[  Clifton  et  al.||20ool  iChambers  and  the  Ce- 


cil  Group  2004) .  However,  typechecking  multiple  dispatch  in  a  modular  fashion  becomes  very 
difficult  in  the  presence  of  multiple  inheritance — precisely  because  of  the  diamond  problem. 

As  previously  noted,  I  focus  on  external  methods  (also  known  as  open  classes),  which  are  es¬ 
sentially  multimethods  that  dispatch  on  the  first  argument  only  (corresponding  to  the  receiver 
of  an  ordinary  method).  As  previously  described  in  Section  [2.4.2!  multimethods  with  asym¬ 
metric  dispatching  semantics  (where  the  order  of  arguments  affects  dispatch)  can  be  translated 
to  external  methods  in  a  straightforward  manner.  Thus,  my  language  proposal  is  applicable  to 
languages  with  multimethods  as  well."'^ 


■^It  happens  that  the  Unity  solution  is  applicable  to  languages  with  either  asymmetric  or  symmetric  dis- 


64 


Chapter  3.  Multiple  Inheritance 


To  see  why  diamond  inheritance  causes  problems,  consider  the  following  definition  of  the 
external  method  seek  (defined  externally  for  illustrative  purposes): 

method  Stream. seek  ( 

Stream. seek:  ( )  ^  long  ^  unit  =  fn  _  -->  ( )  //default  implementation:  do  nothing 
InputStream.seek:  ()  =?■  long  ^  unit  =  . .  .  //  seek  if  first  arg  <=  eofPos 
OutputStream.seek:  ( )  long  ^  unit  =  .  .  .  //if  first  arg  >  eofPos,fill  with  zeros 


inOutStream.seek  1 0  //  ambiguous! 

In  the  context  of  our  diamond  hierarchy,  this  method  definition  is  ambiguous — what  if  seek()  is 
called  on  an  object  of  type  InputOutputStream?  Unfortunately,  it  is  difficult  to  perform  a  modular 
check  to  determine  this  fact.  When  typechecking  the  definition  of  seek(),  we  cannot  search 
for  a  potential  sub-brand  of  both  InputStream  and  OutputStream,  as  this  analysis  would  not  be 
modular.  And,  when  typechecking  InputOutputStream,  we  cannot  search  for  external  methods 
defined  on  both  of  its  super-brands,  as  that  check  would  not  be  modular,  either.  A  detailed 
description  of  the  conditions  for  modularity  is  provided  in  Sect. 


3.7.3 


Note  that  this  problem  is  not  confined  to  multiple  (implementation)  inheritance — it  arises 
in  any  scenario  where  an  object  can  have  multiple  dynamic  types  (or  tags)  on  which  dispatch  is 
performed.  For  instance,  the  problem  appears  if  dispatch  is  permitted  on  Java  interfaces,  as  in 
JPred  [Frost  and  Millstein  20o6|. 


3.3  Previous  Solutions 


Here,  I  describe  previous  solutions  that  specifically  address  the  object  initialization  and  modular 
multiple  dispatch  problems.  Additional  related  work  is  described  in  Sect.|3.8| 


Object  Initialization 


Languages  that  attempt  to  solve  the  object  initialization  problem  include  Eiffel  |Meyer||i997|, 
C++  [Ellis  and  Stroustrup||i99o|,  Scala  [Odersky  2007 1  and  Smalltalk  with  stateful  traits  |Ber^ 
et  al.|20o8|. 

In  Eiffel,  even  though  (by  default)  only  one  instance  of  a  repeatedly  inherited  class  is  included 
(e.g..  Stream),  when  constructing  an  InputOutputStream,  the  Stream  constructor  is  called  twice. 
This  has  the  advantage  of  simplicity,  but  unfortunately  it  does  not  provide  the  proper  seman¬ 
tics;  Stream’s  constructor  may  perform  a  stateful  operation  (e.g.,  allocating  a  buffer),  and  this 
operation  would  occur  twice. 

In  C++,  if  virtual  inheritance  is  used  (so  that  there  is  only  one  copy  of  Stream),  the  con¬ 
structor  problem  is  solved  as  follows:  the  calls  to  the  Stream  constructor  from  InputStream 
and  OutputStream  are  ignored,  and  InputOutputStream  must  call  the  Stream  constructor  explic¬ 
itly.  (Since  there  is  no  default  Stream  constructor,  this  call  cannot  be  automatically  generated.) 
Though  the  Stream  constructor  is  called  only  once,  this  awkward  design  has  the  problem  that 


patch  semantics— the  latter  introduces  a  few  orthogonal  typechecking  issues.  Millstein  and  others  provide  a 
detailed  discussion  of  the  topic  [Millstein  et  al.  2002  Millstein|2oo3|. 


3.3-  Previous  Solutions 
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constructor  calls  are  ignored.  The  semantics  of  InputStream  may  require  that  the  Stream  fields 
be  constructed  in  a  particular  manner,  but  C++  effectively  ignores  this  dependency. 

Scala  provides  a  different  solution:  trait  constructors  may  not  take  arguments.  (Scala  traits 
are  abstract  classes  that  may  contain  state  and  may  be  multiply  inherited.)  This  ensures  that 
InputStream  and  OutputStream  call  the  same  super-trait  constructor,  causing  no  ambiguity  for 
InputOutputStream.  Though  this  design  is  simple  and  elegant,  it  restricts  expressiveness.  (In 
fact,  for  the  next  major  release,  the  Scala  designers  wish  to  attain  a  solution  that  permits  trait 
constructor  arguments  |Washburn||20o8 1.) 

Smalltalk  with  stateful  traits  [Bergel  et  ah  2008 1  does  not  contain  constructors,  but  by  con¬ 
vention,  objects  are  initialized  using  an  initialize  message.  Unfortunately,  this  results  in  the  same 
semantics  as  Eiffel;  here,  the  Stream  constructor  would  be  called  twice  |Bergel|20o8|.  The  only 
way  to  avoid  this  problem  would  be  to  always  define  a  special  initializer  that  does  not  call  the 
superclass  initializer.  Requiring  that  the  programmer  define  such  a  method  essentially  means 
that  the  C++  solution  must  be  hand-coded.  Aside  from  being  tedious  and  error-prone,  this  has 
the  same  drawbacks  as  the  C++  semantics. 

Mixins  and  (stateless)  traits  do  not  address  the  object  initialization  problem  directly,  but 
instead  restrict  the  language  so  that  the  problem  does  not  arise  in  the  first  place.  I  compare 


Unity  to  each  of  these  designs  in  Sect.  3.8 


Modular  Multiple  Dispatch 


There  are  two  main  solutions  to  the  problem  of  modular  typechecking  of  multiple  dispatch  (or 
external  methods)  in  the  presence  of  multiple  inheritance.  The  first  solution  is  to  simply  disallow 
multiple  inheritance  across  module  boundaries;  this  is  the  approach  taken  by  the  “System  M” 
variant  of  Dubious  |  Millstein  and  Chambers  2002) .  Obviously,  the  disadvantage  here  is  the  loss 
of  expressiveness. 

JPred  ||Frost  and  Millstein||20o6|  and  Fortress  [Allen  et  aL]|2007|  take  a  different  approach. 
The  diamond  problem  arises  in  these  languages  due  to  multiple  interface  inheritance  and  mul¬ 
tiple  trait  inheritance,  respectively.  In  these  languages,  the  typechecker  ensures  that  external 
methods  are  unambiguous  by  requiring  that  the  programmer  always  specify  a  method  for  the 
case  that  an  object  is  a  subtype  of  two  or  more  incomparable  interfaces  (or  traits).  In  our  streams 
example,  the  programmer  would  have  to  provide  a  method  like  the  following  (in  JPred  syntax): 


void  seek( Stream  s,  long  pos)  when  s@InputStream  &&  s@OutputStream  { } 


(In  Fortress,  the  method  would  be  specified  using  intersection  types.)  Note  that  in  both  lan¬ 
guages,  this  method  would  have  to  be  defined  for  every  subset  of  incomparable  types,  regardless 
of  whether  a  type  like  InputOutputStream  is  ever  defined.  That  is,  even  if  two  types  will  never 
have  a  common  subtype,  the  programmer  must  specify  a  disambiguating  method,  one  that  per¬ 
haps  throws  an  exception.  ^  Thus,  the  problem  with  this  approach  is  that  the  programmer  is 
required  to  write  numerous  additional  methods — exponential  in  the  number  of  incomparable 


^In  Fortress,  the  programmer  may  specify  that  two  traits  are  disjoint,  meaning  that  there  will  never  be  a 
subtype  of  both.  To  allow  modular  typechecking,  this  disjoint  specification  must  appear  on  one  of  the  two 
trait  definitions,  which  means  that  one  must  have  knowledge  of  the  other;  consequently,  this  solution  lacks 
sufficient  extensibility  and  scalability. 
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types — some  of  which  may  never  be  called.  JPred  alleviates  the  problem  somewhat  by  providing 
syntax  to  specify  that  a  particular  branch  should  be  preferred  in  the  case  of  an  ambiguity,  but 
it  may  not  always  be  possible  for  programmers  to  know  in  advance  which  method  should  be 
preferred. 

Neither  JPred  interfaces  nor  Fortress  traits  may  contain  state  and  thus  the  languages  do  not 
provide  a  solution  to  the  object  initialization  problem;  the  language  Dubious  does  not  either,  as 
it  does  not  contain  constructors. 


3.4  Multiple  Inheritance  in  Unity 

This  section  first  gives  an  informal  description  of  Unity’s  multiple  inheritance  features,  along 
with  an  illustrative  example.  I  show  how  Unity  solves  our  two  main  problems  (object  initializa¬ 
tion  and  modularly  typchecking  external  methods)  and  then  provide  a  more  detailed  account  of 
the  typechecking  rules.  This  section  also  provides  additional  comparison  to  the  relevant  related 
work. 


3.4.1  Overview 


Unity’s  multiple  inheritance  design  is  based  on  the  intuition  that  there  are  semantic  relationships 
between  brands  that  are  not  captured  by  inheritance,  and  that  if  brand  hierarchies  could  express 
richer  interconnections,  inheritance  diamonds  need  not  exist.  Suppose  the  concrete  brand  C 
extends  A.  As  noted  by  Scharli  et  al.  I2003I,  it  is  beneficial  to  recognize  that  C  serves  two  roles: 
(1)  it  is  a  generator  of  instances;  and  (2)  it  is  a  unit  of  reuse,  through  sub-branding.  In  the  first 
role,  inheritance  is  the  implementation  strategy  and  must  be  preserved  (assuming  extensive  re¬ 
design  is  not  feasible).  In  the  second  role,  however,  it  is  possible  to  transform  the  brand  hierarchy 
to  one  where  an  inheritance  dependency  between  C  and  A  is  declared  and  where  sub-brands  of 
C  inherit  from  both  C  and  A.  This  notion  of  inheritance  dependency  is  the  key  distinguishing 
feature  of  multiple  inheritance  in  Unity:  while  multiple  inheritance  is  permitted,  inheritance 
diamonds  are  forbidden. 

Consider  the  inheritance  diamond  of  Fig.  EH  To  translate  this  hierarchy  to  Unity, 
InputStream  would  be  made  abstract®  and  its  relationship  to  Stream  would  be  changed  from  in¬ 
heritance  to  an  inheritance  dependency,  which  means  that  (concrete)  sub-brands  of  InputStream 
must  also  inherit  from  Stream.  In  other  words,  InputStream  requires  the  presence  q/Stream  in 
the  extends  clause  of  concrete  sub-brands,  but  it  need  not  extend  Stream  itself.  Since  InputStream 
is  now  abstract  (making  it  serve  only  as  a  unit  of  reuse),  it  can  be  safely  treated  as  a  subtype  of 
Stream.  However,  any  concrete  sub-brands  of  InputStream  (generators  of  instances),  must  also 
inherit  from  Stream.  Accordingly,  InputOutputStream  must  inherit  from  Stream  directly. 

This  notion  of  an  inheritance  dependency  is  reified  using  the  requires  keyword,  a  generalized 
form  of  a  similar  construct  in  Scala  |  Odersky  and  Zenger||2005|  Odersky|2007|.^ 


®  While  the  calculus  does  not  have  a  formal  notion  of  “abstract”  and  “concrete,”  it  ensures  that  conceptually 
“abstract”  brands  may  not  be  instantiated. 

^In  Scala,  requires  is  used  to  specify  the  type  of  a  method’s  receiver  (i.e.,  it  is  a  selftype),  and  does  not  create 
a  subtype  relationship.  As  far  as  the  Scala  team  is  aware,  our  proposed  use  of  requires  is  novel  |Washbur'n 
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sion  in  gray.  Italicized  brand  names  indicate  abstract  brands,  solid  lines  indicate  extends,  and 
dashed  lines  indicate  requires. 


Definition  3.1  (Requires). 

When  a  brand  C  requires  a  brand  B,  we  have  the  following: 

1.  C  objects  may  not  be  created  (i.e.,  C  is  abstract) 

2.  C  objects  are  subtypes  of  B  objects  (CO  <  BO),  but  C  is  not  a  sub-brand  of  B  (C  ^  B) 

3.  Sub-brands  of  C  must  either  require  B  themselves  (making  them  abstract)  or  extend  B 
(allowing  them  to  be  concrete).®  This  is  achieved  by  including  a  requires  B'  or  extends  B' 
clause,  where  B'  is  a  sub-brand  of  B. 


In  essence,  “C  requires  B”  defers  the  actual  inheritance  of  B  (i.e.,  sub-branding),  but  provides  a 
guarantee  that  C’s  concrete  sub-brands  will  extend  B  (or  one  of  its  sub-brands). 

In  the  original  hierarchy,  InputStream 


The  revised  stream  hierarchy  is  displayed  in  Fig. 


3.2 


served  as  both  generator  of  instances  and  a  unit  of  reuse.  In  the  revised  hierarchy,  we  di¬ 
vide  the  brand  in  two — one  for  each  role.  The  brand  ConcreteInputStream  is  the  gener¬ 
ator  of  instances,  and  the  abstract  brand  InputStream  is  the  unit  of  reuse.  Accordingly, 
InputStream  requires  Stream,  and  ConcreteInputStream  extends  both  InputStream  and  Stream. 
The  concrete  brand  InputOutputStream  extends  each  of  Stream,  InputStream,  and  OutputStream, 
creating  a  suhtyping  diamond,  but  not  a  sub-branding  diamond. 

The  code  for  InputStream  will  be  essentially  the  same  as  before,  except  for  the  call  to  its  super 
constructor  (explained  further  below).  Because  InputStream  is  a  subtype  of  Stream,  it  may  use 
all  the  fields  and  methods  of  Stream,  without  having  to  define  them  itself. 

Programmers  may  add  another  dimension  of  stream  behavior  through  additional  abstract 
brands,  for  instance  EncryptedStream.  EncryptedStream  is  a  type  of  stream,  but  it  need  not  extend 
Stream,  merely  require  it.  Concrete  sub-brands,  such  as  EncryptedInputStream  must  inherit  from 


200^. 

*This  propagation  of  the  requires  clause  is  not  strictly  necessary  and  could  be  inferred;  however,  it  is  in¬ 
cluded  by  analogy  with  Scala  as  well  as  to  simplify  the  calculus. 
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Stream,  which  is  achieved  by  extending  ConcreteInputStream.  (It  would  also  be  possible  to  extend 
Stream  and  InputStream  directly.) 

The  requires  relationship  can  also  be  viewed  as  declaring  a  semantic  “mixin” — if  B  requires 
A,  then  B  is  effectively  stating  that  it  is  an  extension  of  A  that  can  be  “mixed-in”  to  clients.  For 
example,  EncryptedStream  is  enhancing  Stream  by  adding  encryption.  Because  the  relationship 
is  explicitly  stated,  it  allows  B  to  be  substitutable  for  A. 

Using  requires  is  preferable  to  using  extends  because  the  two  brands  are  more  loosely 
coupled.  For  example,  we  could  modify  EncryptedInputStream  to  require  InputStream  (rather 
than  extend  ConcreteInputStream).  A  concrete  sub-brand  of  EncryptedInputStream  could  then 
also  extend  a  sub-brand  of  InputStream,  such  as  BufferedInputStream,  rather  than  extending 
InputStream  directly.  In  this  way,  different  pieces  of  functionality  can  be  combined  in  a  flexible 
manner  while  avoiding  the  complexity  introduced  by  inheritance  diamonds. 

Object  Initialization 

Because  there  are  no  inheritance  diamonds,  the  object  initialization  problem  is  trivially  solved. 
Note  that  if  brand  C  requires  A,  it  need  not  (and  should  not)  call  As  constructor,  since  C  does 
not  inherit  from  A.®  In  our  example,  InputStream  does  not  call  the  Stream  constructor,  while 
ConcreteInputStream  calls  the  constructors  of  its  super-brands,  InputStream  and  Stream.  Thus, 
a  subtyping  diamond  does  not  cause  problems  for  object  initialization. 

This  may  seem  similar  to  the  C++  solution;  after  all,  in  both  designs,  InputOutputStream  calls 
the  Stream  constructor.  However,  the  Unity  design  is  preferable  for  two  reasons:  a)  there  are  no 
constructor  calls  to  non-direct  super-brands,  and,  more  importantly,  b)  constructor  calls  are 
never  ignored.  In  the  C++  solution,  InputStream  may  expect  a  particular  Stream  constructor  to 
be  called;  as  a  result,  it  may  not  be  properly  initialized  when  this  call  is  omitted.  Essentially,  Unity 
does  not  allow  the  programmer  to  create  constructor  dependencies  that  cannot  be  enforced. 


Modular  Multiple  Dispatch 


A  similar  principle  solves  the  problem  of  modular  multiple  dispatch.  In  Unity,  a  method 
may  only  override  a  method  in  a  super-brand,  not  a  required  brand.^°  So,  the  definitions  of 
InputStream. seek  and  OutputStream.seek  cannot  not  override  Stream. seek — methods  defined  in 
an  external  method  block  must  be  a  sub-brand  of  the  method’s  owner  brand. 

Let  us  suppose  for  a  moment  that  all  brands  in  Fig. 


3-2 


have  been  defined,  except 
(Though 


3-3 


InputOutputStream.  Accordingly,  we  would  re-write  the  seek  methods  as  in  Fig. 
these  definitions  are  slightly  more  verbose  than  before,  syntactic  sugar  could  be  provided.)  Note 
that  seekinput  and  seekOutput  could  just  as  easily  have  been  ordinary  functions  (lambda  expres¬ 
sions)  in  this  example,  as  there  is  no  overriding  here. 


®While  the  formal  system  does  not  include  constructors  (fields  are  simply  initialized  directly  when  an 
object  is  created),  this  would  be  quite  a  straightforward  extension  of  the  system. 

^°Note  that  it  would  be  possible  to  remove  this  restriction  for  internal  methods,  as  any  ambiguity  is  easily 
detected  modularly.  However,  such  a  semantics  unduly  complicates  the  formal  system  and  does  not  add  any 
expressiveness.  This  is  due  to  the  fact  that  Unity  does  not  define  any  sort  of  linearization,  so  programmers 
must  define  this  manually  anyway. 
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//  helper  methods,  could  also  use  lambda  expressions 

method  InputStream.seekInput:  ( )  =>  long  ^  unit  =  . .  . 
method  OutputStream.seekOutput  '.{)=>  long  ^  unit  =  . .  . 

method  Stream. seek  ( 

Stream. seek:  ( )  ^  long  ^  unit  =  fn  _  -->  ( )  //default  implementation:  do  nothing 
ConcreteInputStream.seek:  ( )  ^  long  ^  unit  = 
fn  pos:  long  -->  this.seekinput  pos 
ConcreteOutputStream.seek:  ()  ^  long  ^  unit  = 
fn  pos:  long  -->  this.seekOutput  pos 


Figure  3.3:  Re-writing  the  seek  method  in  Unity. 


Note  that  the  typechecker  does  not  require  that  a  disambiguating  method  be  provided 
for  “InputStream  &&  OutputStream”  unlike  JPred  and  Fortress.  If  a  programmer  later  defines 
InputOutputStream,  but  does  not  re-define  seek,  the  default  implementation  of  Stream. seek  will 
be  inherited.  An  external  or  internal  method  for  InputOutputStream  can  then  be  implemented, 
perhaps  one  that  calls  OutputStream. doSeek(). 

Here,  it  is  of  key  importance  that  sub-brand  diamonds  are  disallowed;  because  they  cannot 
occur,  external  methods  can  be  easily  checked  for  ambiguities.  Swhtyping  diamonds  do  not  cause 
problems,  as  external  method  overriding  is  based  on  sub-branding. 


Using  requires 


Introducing  two  kinds  of  brand  relationships  raises  the  question:  when  should  programmers  use 
requires,  rather  than  extends?  A  rule  of  thumb  is  that  requires  should  be  used  when  a  brand  is  an 
extension  of  another  brand  and  is  itself  a  unit  of  reuse.  If  necessary,  a  concrete  brand  extending 
the  required  brand  (such  as  ConcreteInputStream)  could  also  be  defined  to  allow  object  creation. 
Note  that  this  concrete  brand  definition  would  be  trivial,  likely  containing  only  a  constructor. 
On  the  other  hand,  when  a  brand  hierarchy  contains  multiple  disjoint  alternatives  (such  as  in 
the  AST  example  in  the  next  section),  extends  should  be  used;  the  no-diamond  property  is  also 
a  semantic  property  of  the  brand  hierarchy  in  question. 

The  above  guideline  may  result  in  programmers  defining  more  abstract  brands  (and  corre¬ 
sponding  concrete  brands)  than  they  may  have  otherwise  used.  However,  some  argue  that  it  is 
good  design  to  make  a  class  (or  brand)  abstract  whenever  it  can  be  a  base  class  (or  brand).  This 
is  in  accordance  with  the  design  of  classes  in  Sather  fSzyperski  et  al.||i993|,  traits  in  Scala  and 
Fortress  |  Odersky|2007  Allen  et  ^[2008  2007),  and  the  advice  that  “non-leaf”  classes  in  C++ 
be  abstract  | Meyers|i992|.  In  Sather  and  Fortress,  for  example,  only  abstract  classes  may  have 


descendants;  concrete  classes  (called  “objects”  in  Fortress)  form  the  leaves  of  the  inheritance 


hierarchy  |  Szyperski  et  al.||i993 1 .  Futhermore,  a  language  could  define  syntactic  sugar  to  ease 


the  task  of  creating  concrete  brand  definitions;  such  a  design  is  sketched  in  Sect.  3.5.4 
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3.4.2  Typechecking  Multiple  Inheritance 


Here,  I  describe  the  multiple  inheritance  typechecking  rules  at  a  high  level,  to  provide  an  intu¬ 
ition  as  to  why  typechecking  is  modular.  Sect.  3.7  completes  the  discussion  of  Unity’s  formalism 


(i.e.,  the  highlighted  portions  of  Sect.  [2^  and  also  provides  a  detailed  argument  of  its  modular¬ 
ity. 


Brands 


As  mentioned,  inheritance  diamonds  are  forbidden  in  Unity.  Concretely,  we  have  the  following 
condition: 


Bi.  If  a  brand  B  extends  Ci  and  C2  then  there  must  not  exist  some  D,  other  than  Object,  such 
that  both  Cl  and  C2  are  sub-brands  of  D. 

A  special  case  is  made  for  the  brand  Object — the  root  of  the  inheritance  hierarchy,  since  every 
brand  directly  or  indirectly  extends  it.  (Otherwise,  a  brand  could  never  extend  two  unrelated 
brands — the  existence  of  Object  would  create  a  diamond.)  Note  that  this  does  not  result  in  the 
object  initialization  problem,  because  Object  has  only  a  no-argument  constructor.  Also,  this 
condition  does  not  preclude  a  brand  from  inheriting  from  two  concrete  brands  if  this  does  not 
form  a  diamond. 


Additionally,  our  convention  of  unique  method  name  introductions  (Sect.l2.4i3 1  ensures  that 


ambiguities  cannot  arise  when  two  unrelated  brands  A  and  B  coincidentally  have  the  same  name 
and  a  third  brand  inherits  from  both  A  and  B.^^ 


External  Methods 


The  restrictions  on  external  methods,  conditions  £i -£3,  were  enumerated  in  Sect. [2.4.^  While 
all  three  conditions  are  the  same  as  those  in  System  M,  that  language  did  not  allow  multiple 
inheritance  across  module  boundaries.  In  Unity  this  restriction  is  removed  by  ensuring  that 
diamond  inheritance  does  not  occur — condition  Bi.  (Note  that  in  Unity,  each  brand  and  each 
top-level  method  declaration  is  in  its  own  “module.”) 

Recall  that  the  rationale  for  conditions  Ei  and  £2  were  described  in  Sect.  [2.4.^  but  the  dis¬ 
cussion  of  condition  £3  was  deferred.  This  condition  is  imposed  for  modular  ambiguity  checking 
in  the  presence  of  multiple  inheritance: 


£3.  When  an  external  method  family  m  is  introduced,  it  must  declare  an  owner  brand  C:  this 
specifies  that  the  method  family  is  rooted  at  C.  C  must  be  a  proper  subtype  of  Object,  the 
root  of  the  inheritance  hierarchy.  An  external  method  definition  m  for  brand  D  is  valid 
only  if  D  is  a  sub-brand  of  C. 

Condition £3  ensures  that  diamonds  with  Object  at  the  top  (permitted  by  condition  Bi)  do  not 
cause  an  ambiguity.  Concretely,  consider  the  following  method  definition: 


^^Incidentally,  this  is  not  the  convention  used  in  Java  interfaces,  but  is  that  of  C#. 
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Figure  3.4:  The  AST  node  example  in  Unity.  Abstract  brands  and  abstract  methods  are  set  in 
italic.  The  visibility  modifiers  ‘+’,  and  '#’  indicate  public,  private  and  protected,  respectively. 


method  Object. q  (  //  illegal  definition-owner  cannot  be  Object 
Stream. g  '.{)=>  unit  =  .  . . 

Foo.g  :  ( )  =>  unit  =  . .  . 

) 

brand  Bar  extends  Stream,  Foo  (...)  //  problem!  two  versions  of  g{)! 


If  this  were  valid  code,  there  would  exist  a  method  definition  g  ()  for  each  of  Stream  and  Foo. 
In  this  case.  Bar  would  inherit  two  equally  legitimate  definitions  of  g  ( ) .  For  typechecking  to  be 
modular,  when  checking  Bar,  we  should  not  have  to  check  all  definitions  of  external  methods, 
including  g () .  Note  that  not  specifying  an  owner  brand  would  have  the  same  effect  as  using 
Object  as  an  owner. 


Additionally,  condition  £3  ensures  that  diamond  ?,\}btyping  (as  opposed  to  sub-branding) 
does  not  result  in  a  brand  inheriting  the  same  external  method  through  more  than  one  path. 
If  overriding  were  permitted  based  on  subtyping,  the  problem  described  with  diamond  inheri¬ 
tance  (Sect. [3^  would  re-appear. 

The  owner  brand  is  also  useful  for  implementing  unique  qualified  names,  described  in 
(A  related  issue,  defining  two  external  methods  with  the  same  name  m,  can  be  re- 


2.4.3 


Sect. 

solved  by  using  a  naming  convention  for  modules.) 


3.5  Example:  Abstract  Syntax  Trees 


Consider  a  simple  type  hierarchy  for  manipulating  abstract  syntax  trees  (ASTs),  such  as  the 
one  in  Fig.  3.4  The  original  hierarchy  is  the  one  on  the  left,  which  consists  of  ASTNode,  Num, 


Var,  and  Plus.  An  ASTNode  contains  a  reference  pointing  to  its  parent  node,  as  indicated  in  the 
figure.  Each  of  the  concrete  sub-brands  of  ASTNode  implements  its  own  version  of  the  abstract 
ASTNode. eval  ( )  method.  For  the  sake  of  brevity,  methods  for  accessing  the  state  of  Num  and  Var 
have  been  omitted. 
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Suppose  that  after  we  have  defined  these  brands,  we  wish  to  add  a  new  method  that  operates 
over  the  AST.  For  instance,  we  may  want  to  check  that  variables  are  declared  before  they  are  used 
(assuming  a  variable  declaration  statement).  Since  Unity  supports  external  methods,  a  method 
defCheck( )  could  be  added  externally  as  follows: 

method  ASTNode.defCheck  (  //external  method 
ASTNode.defCheck '.{)=>  bool  =  .  .  . 

Num.defCheck '.{)=>  bool  =  .  .  . 

Var.defCheck :  ( )  =►  bool  =  .  .  . 

Plus.defCheck :  ( )  =>  bool  =  .  . . 

) 

Note  that  the  programmer  would  only  have  to  define  cases  for  Num,  Var  and  Plus;  she  need 
not  specify  what  method  should  be  called  when  an  object  has  a  combination  of  these  types — 
such  a  situation  cannot  occur  (as  there  are  no  diamonds). 

Now,  suppose  we  wish  to  add  debugging  support  to  our  AST,  after  the  original  hierarchy  is 
defined.  Each  node  now  additionally  has  a  source  location  field,  DebugNode. location.  Debugging 
support,  on  the  right  side  of  the  figure,  is  essentially  a  new  dimension  of  AST  nodes  that  has 
a  dependency  on  ASTNode.  We  express  this  using  requires.  Now,  brands  like  DebugPlus  can 
multiply  inherit  from  ASTNode  and  DebugNode  without  creating  a  sub-branding  diamond.  In 
particular,  DebugPlus  does  not  inherit  two  copies  of  the  parent  field,  because  DebugNode  is  a 
subtype,  but  not  a  sub-brand,  of  ASTNode.  Thus,  the  no-diamond  property  allows  fields  and 
multiple  inheritance  to  co-exist  gracefully. 

In  this  example,  each  of  these  brands  has  a  method  eval()  which  evaluates  that  node  of 
the  AST,  as  in  the  code  in  Fig.|3.5[  Suppose  we  intend  DebugNode  to  act  as  a  generic  wrapper 
brand  for  each  of  the  sub-brands  of  ASTNode.  This  can  be  implemented  by  using  a  dynamically- 
dispatched  super  call  of  the  form  ASTNode.super.eval( )  after  performing  the  debug-specific 
functionality  (in  this  case,  printing  the  node’s  string  representation).  The  prefix  ASTNode. super 
means  “find  the  first  super-brand  of  this  that  implements  ASTNode.”  At  runtime,  when  eval() 
is  called  on  an  instance  of  DebugPlus,  the  chain  of  calls  proceeds  as  follows:  DebugPlus. eval  ( ) 

I — ^  DebugNode. eval  ( )  1 — >  Plus. eval  ( ) .  If  the  dynamically-dispatched  super  call  behaved  as  an 
ordinary  super  call,  it  would  fail — DebugNode  has  no  super-brand. 

Each  of  the  DebugNode  sub-brands  implements  its  own  eval()  method  that  calls 
DebugNode. eval  ( )  with  an  ordinary  super  call.  (This  could  be  omitted  if  the  language  linearized 
method  overriding  based  on  the  order  of  inheritance  declarations,  as  described  below.)  Dynamic 
super  calls  are  a  generalization  of  ordinary  super  calls,  when  the  qualifier  brand  is  a  required 
brand. 


3.5.1  Multiple  Inheritance  and  Metho  d  N ames 


The  AST  example  ignored  the  details  of  simple  and  qualified  method  names,  but  we  will  now 
examine  the  effect  of  multiple  inheritance  on  naming. 

3.4.1J  method  override  is  based  on  subclassing,  rather  than  subtyp- 


As  mentioned  in  Sect. 


ing.  Consequently,  in  the  above  example,  DebugNode. eval  is  not  in  the  same  method  family  as 
ASTNode. eval  and  it  would  therefore  have  a  different  qualified  name.  Subclasses  of  DebugNode, 
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brand  DebugNode  requires  ASTNode  ( 
method  eval:  ()  =>  ASTNode  = 
print(this.toString( ) ) ; 

ASTNode. super.eval  //dynamic  super  call 

) 

brand  DebugPlus  extends  DebugNode,  Plus  ( 
method  eval:  ( )  ^  ASTNode  = 

DebugNode. super.eval  //  ordinary  super  call 

) 


Figure  3.5:  Implementing  a  mixin-like  debug  brand  using  dynamically-dispatched  super  calls. 


such  as  DebugPlus,  would  inherit  both  ASTNode_eval  and  DebugNocle_eval  and  would  override 
the  former  method  to  call  the  latter. 

It  would  be  interesting  to  extend  Unity  to  allow  DebugNode. eval  to  be  in  the  same  method 
family  as  ASTNode. eval,  particularly  if  the  language  also  added  some  form  of  linearization  se¬ 
mantics.  For  example,  if  DebugPlus  inherited  from  DebugNode,  ASTNode,  this  could  mean  that 
the  DebugNode. eval  definition  is  to  take  precedence.  As  this  is  largely  an  orthogonal  issue,  how¬ 
ever,  I  have  omitted  linearization  from  the  language. 


3.5.2  Utility  of  requires 

It  may  seem  that  the  main  benefit  of  requires  is  that  it  provides  subtyping  without  sub-branding. 


which  has  already  been  implemented  in  many  languages  (e.g. 

Black  et  al.||i986 

Hutchinson 

1987 

Raj  et  al.||i99i 

Cook  et  al. 

1990I 

Szyperski  et  al.||i993| 

Liskov  et  al.||i994 

Chambers  and 

the  Cecil  Group||2004  iJohnsen  et  al.lboohl).  In  fact.  Unity  as  described  in  the  previous  chap- 

ter  already  separated  the  notion  of  subtype  and  sub-brand!  So,  if  this  were  the  only  benefit  of 
requires,  it  would  seem  that  it  could  be  omitted  from  the  language.  But,  as  it  turns  out,  the  utility 
of  requires  lies  in  the  fact  that  it  establishes  a  stronger  relationship  than  mere  subtyping — it  en¬ 
forces  the  requirement  that  subclasses  use  a  particular  inheritance  path  in  order  to  implement 
the  required  functionality.  This  in  turn  affects  two  seemingly  orthogonal  issues:  dynamically- 
dispatched  super  calls  and  brand-private  state. 


Dynamically-dispatched  super  calls.  In  the  AST  node  example,  we  saw  that  it  was  possible 
to  implement  mixin-like  functionality  using  the  dynamically-dispatched  super  call,  where  the 
call  was  dispatched  to  the  brand  that  eventually  implemented  the  required  functionality.  In  a 
system  without  requires,  however,  designing  a  similar  feature  would  be  decidedly  non-trivial  (in 
fact,  it  is  possible  that  method  calls  could  easily  become  ambiguous).  Thus,  I  argue  that  a)  this 
is  a  useful  feature  (as  illustrated  in  the  example  above)  and  b)  a  coherent  language  design  would 
need  to  capture  some  notion  of  inheritance  dependency  in  order  to  implement  such  a  feature. 
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Brand-private  state.  In  any  language  that  separates  sub-branding/subclassing  and  subtyp¬ 
ing  (using  either  nominal  or  structural  subtyping),  an  interface  cannot  contain  private  mem¬ 
bers.  Otherwise,  superclasses  would  be  able  to  access  private  members  defined  in  subclasses — a 
violation  of  information  hiding. 

Unfortunately,  this  restriction  can  be  problematic  for  defining  binary  methods  such  as  the 
equals  method;  its  argument  type  must  contain  those  private  members  for  the  method  be  able 
to  access  them.  But,  for  this  type  to  contain  private  members,  it  must  be  tied  to  a  particular  class 
implementation,  as  only  subclasses  (as  opposed  to  subtypes)  should  conform  to  this  type. 

Concretely,  consider  the  following  program  (in  a  fictional  Java-like  syntax): 

class  A  { 

private  int  i; 

boolean  equals(A  other)  { 

// can  access  oXhei .'\? 

] 

] 

class  B  subtypes  A  { 

//declare  \  ? 

] 

Suppose  that  the  subtypes  keyword  provides  nominal  subtyping  without  inheritance  (but  with¬ 
out  the  additional  constraints  of  requires).  The  question  then  arises:  are  private  members  con¬ 
sidered  when  checking  subtyping?  If  so,  then  B  must  declare  a  private  field  i.  Unfortunately,  this 
also  means  that  A. equals  can  access  B.i,  which  violates  information  hiding;  one  class  should  not 
be  able  to  access  private  members  defined  in  another  class.  On  the  other  hand,  if  we  assume 
that  subtyping  does  not  include  private  members,  then  A. equals  cannot  access  other. i,  which  is 
problematic  if  the  definition  of  equality  depends  on  this  field.  An  analogous  problem  occurs  if 
structural  subtyping  is  used.^^ 

The  problem  can  be  avoided  if  inheritance  or  requires  is  used  for  types  that  contain  binary 
methods.  Since  requires  is  tied  to  a  particular  class,  if  we  change  the  above  code  to  B  requires  A 
(or  B  extends  A),  then  A. equals  (A  other)  may  safely  access  other. i,  even  if  an  object  of  type  B  is 
passed  to  this  method.  Note  that  an  information  hiding  problem  does  not  arise  here — the  private 
state  has  not  been  redefined  in  B,  but  is  rather  (eventually)  inherited  from  A  in  the  concrete  B 
implementation  that  was  passed  in. 


In  summary,  requires  provides  at  least  two  benefits  in  addition  to  sub  typing  without  sub¬ 
branding:  it  makes  it  possible  to  define  a  straightforward  semantics  for  a  form  of  dynamically- 
dispatched  super  call,  and  it  makes  possible  the  definition  of  brand-private  state.  The  former  is 
useful  for  defining  mixin-like  classes,  and  the  latter  is  important  for  defining  binary  methods, 
such  as  equals. 


^^I  am  assuming  here  that  brand-private  state  is  the  desirable  semantics.  If  an  object-private  semantics 
were  used,  no  problems  would  arise,  but  it  would  also  be  impossible  to  define  the  appropriate  equals  method. 


3.5-  Example:  Abstract  Syntax  Trees 
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3.5.3  Comparison  to  Other  Languages 


In  this  section,  the  AST  example  is  encoded  in  other  languages  (those  with  single  inheritance, 
mixins,  or  traits)  and  the  resulting  designs  are  compared  to  that  in  the  example. 


Single  Inheritance 


Figure  3.6:  The  example  of  Fig.js^expressed  in  a  Java-like  language,  resulting  in  a  proliferation 
of  interfaces  and  boilerplate  code.  The  visibility  modifiers  '+( and  '#’  indicate  public,  private 
and  protected,  respectively.  Dashed  lines  represent  extends;  solid  lines  represent  implements. 


This  example  would  be  more  difficult  to  express  in  a  language  with  single  inheritance.  One 
straightforward  design  in  a  Java-like  language  is  presented  in  Fig.  3.6  Multiple  inheritance  is 
simulated  using  interfaces  for  subtyping,  and  composition  for  dispatch.  For  instance,  calls  to 
DebugPlus.getLeftO  are  delegated  to  the  wrapped  IPIus  object.  The  template  method  design 
pattern  is  used  by  DebugNode  to  implement  eval( )  (subclasses  override  getWrapped( )). 


Note  the  addition  of  4  new  interfaces  and  the  boilerplate  code  needed  to  implement  getters, 
setters  and  delegation.  The  problem  would  be  even  worse  if  another  dimension  of  behavior 
were  to  be  added.  Furthermore,  the  design  has  the  problem  that  the  getters  and  setters  have  to 
be  public,  since  they  are  defined  in  an  interface.  For  instance,  the  “parent”  field  in  ASTNode  is 
effectively  fully  visible,  adversely  affecting  information  hiding.  Additionally,  one  would  have  to 
implement  the  visitor  design  pattern  (not  shown)  to  allow  external  traversal  of  the  AST. 
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brand  EnhancedDebugVar  extends  DebugVar  ( 
defLocation :  SourceRef  j 

method  varLocToString:  ( )  =►  string  =  .  . .  //create  user-readable  stringfrom  defLocation 


method  eval:  ( )  ^  ASTNode  = 
print(this. varLocToString) 
DebugNode. super. eval 


Figure  3.7:  Adding  a  new  sub-brand  of  DebugVar 


Mixins 


This  example  would  be  also  difficult  to  express  using  mixins.  Aside  from  the  limitation  that  a 
total  ordering  must  be  specified  during  mixin  composition  [Ducasse  et  al.||2006|,  other  issues 
arise.  Suppose  that  in  a  variation  of  the  previous  example,  we  were  to  add  a  new  sub-brand 
of  DebugVar,  EnhancedDebugVar.  The  intended  semantics  is  that  DebugVar.eval()  prints  the 
variable  name,  while  EnhancedDebugVar. eval  ( )  prints  the  variable  name  and  the  location  where 
the  variable  was  defined  in  the  source  program.  To  implement  this,  we  put  the  functionality  of 
storing  and  printing  a  variable  location  into  EnhancedDebugVar.  Concretely,  we  would  add  the 
code  in  Fig. 
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A  possible  translation  of  this  example  into  Jam  (an  extension  of  Java  with  mixins  |An- 


cona  et  aT]|2003 1)  is  shown  in  Fig.  3.8  First,  we  must  create  mixin  equivalents  of  DebugNode 
and  DebugVar,  which  will  be  prefixed  with  M.  Since  mixins  cannot  inherit  from  one  another, 
MDebugVar  would  not  be  able  to  express  an  explicit  relationship  with  MDebugNode  (nor  Var), 
but  would  instead  have  to  declare  location  and  eval  ( )  (and  left,  right,  etc.)  as  required  members. 


This,  in  turn,  leads  to  two  problems.  First,  MDebugVar  cannot  be  treated  as  a  subtype 
of  MDebugNode,  which  is  a  serious  loss  of  expressiveness  as  compared  to  Unity.  Second — 
and  more  significantly — supposing  that  external  methods  were  to  be  integrated  with  mix¬ 
ins,  it  would  be  impossible  to  write  an  external  method  for  MDebugNode  and  override  it 
for  MDebugVar,  because  there  is  no  relationship  between  the  two  mixins.  That  is,  we  may 
wish  to  write  methods  MDebugNode. m  and  MDebugVar.m  (its  override),  and  have  the  mixin 
MEnhancedDebugVar  inherit  this  latter  definition.  Instead,  the  definition  of  m  must  be  pushed 
down  to  MEnhancedDebugVar,  which  creates  problems  for  code  reuse.  In  particular,  suppose 
that  method  m  and  MEnhancedDebugVar  are  independent  extensions  that  have  no  knowledge 
of  each  other.  In  a  mixin  world,  external  method  definitions  cannot  be  truly  modular  extensions. 

The  heart  of  the  problem  is  that  mixins  are  defined  in  isolation — though  they  can  be  com¬ 
posed,  they  cannot  be  subclasses  (or  even  subtypes)  of  one  another.  Our  proposed  solution 
does  bear  some  similarity  to  mixins,  but  additionally  provides  subtyping,  design  intent  (through 
requires)  and  (no-diamond)  multiple  inheritance. 


3.5-  Example:  Abstract  Syntax  Trees 
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tnlxln  MDebugNode  { 

inherited  ASTNode  parent; 

SourceRef  location; 
inherited  ASTNode  eval()  { 
println(this .toString( ) ); 
return  super. eval(); 

] 

tnixin  MDebugVar  { 

inherited  SourceRef  location; 
inherited  ASTNode  left,  right; 

inherited  String  toStringO  {  }  // use  Location,  Left  and  right  fields 

} 

tnixin  MDebugVarEnhancer  { 

inherited  ASTNode  left,  right; 
defLocation  :  SourceRef; 

inherited  ASTNode  eval()  { 

. . .  //  call  super.  evaL  and  use  defLocation  to  print  out  debug  info 

} 


// psuedo-syntax;  in  Jam,  would  have  to  create  intermediary  classes 
class  EnhancedDebugVar  = 

MDebugVarEnhancer  extends  (MDebugVar  extends  (MDebugNode  extends  Var))  {  } 


Figure  3.8:  Rewriting  parts  of  the  AST  example  using  Jam-style  mixins  |  Ancona  et  al. 
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Traits 


Traits  could  be  used  to  express  this  example,  but  their  lack  of  state  results  in  an  information¬ 
hiding  problem  with  accessors,  a  problem  similar  to  that  of  the  single  inheritance  design.  The 
stateful  traits  design  [Bergel  et  al.|20o8]  does  not  provide  a  mechanism  for  true  information 
hiding,  as  state  can  always  be  “unhidden”  within  classes  composing  the  trait.  In  that  design,  all 
state  is  effectively  “protected”  (in  the  Cf  f  sense  of  the  term). 

A  possible  encoding  of  the  AST  example  into  a  language  with  traits  is  shown  in  Fig. : 
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Note 

the  duplication  of  accessor  methods,  and  the  fact  that  that  traits  such  as  T_ASTNode,  may  not 
define  “state”  that  is  private  to  the  trait — by  definition,  the  composing  class  must  implement  the 
associated  accessor  methods. 


Scala  traits 

Scala  traits  are  fusion  of  ordinary  traits  and  mixins.  Unlike  ordinary  traits,  Scala  traits  may 
contain  state  (thereby  avoiding  the  information  hiding  problem),  and  unlike  ordinary  mixins. 
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Figure  3.9:  The  example  of  Fig.js^expressed  in  a  language  with  traits  (in  the  sense  of  |  Scharli 


et  al.||2003)).  The  visibility  modifiers  ‘+(  and  '#’  indicate  public,  private  and  protected,  re¬ 


spectively. 


Scala  traits  may  define  inheritance  relationships.  Accordingly,  this  particular  example  could  be 
expressed  quite  elegantly  in  Scala.  Unfortunately,  the  problems  of  diamond  inheritance  would 
again  arise.  In  particular,  if  Scala  supported  any  form  of  multimethod  or  external  method,  then 
a  solution  similar  to  that  of  Fortress  or  JPred  would  have  to  be  employed  for  ensuring  that  mul¬ 
timethods  were  unambiguious.  Concretely,  the  definition  of  a  method  similar  to  the  defCheck 
external  method  would  either  be  potentially  ambiguious  or  unduly  difficult  to  implement.  And, 
as  previously  mentioned,  to  avoid  the  object  initialization  problem,  Scala  traits  cannot  have 
constructor  parameters — a  serious  limitation. 

Note  that  Scala  also  has  a  feature  similar  to  what  I  have  called  a  dynamically-dispatched 
super  call.  A  method  can  be  marked  abstract  override,  which  means  that  it  is  an  override  of  a 
yet-to-be-inherited  method.  A  super  call  within  such  a  method  has  the  same  dispatch  semantics 
as  the  Unity  dynamic  super  call. 


3.5.4  Discussion 

Analogy  to  case  analysis 

The  examples  also  illustrate  that  sub-branding,  in  addition  to  providing  inheritance,  defines 
semantic  alternatives  that  may  not  overlap  (such  as  Num,  Var  and  Plus  in  the  example  above). 
Because  they  do  not  overlap,  we  can  safely  perform  an  unambiguous  case  analysis  on  them — that 
is,  external  dispatch.  In  other  words,  external  dispatch  in  Unity  is  analogous  to  case-analyzing 
datatypes  in  functional  programming. 

Here,  I  discuss  some  additional  design  issues,  such  as  encapsulation,  comparison  to  traits, 
and  potential  Unity  extensions. 
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Encapsulation  and  the  Diamond  Problem 


As  noted  by  Snyder,  there  are  two  possible  ways  to  view  inheritance:  as  an  internal  design  deci¬ 
sion  chosen  for  convenience,  or  as  a  public  declaration  that  a  subclass  is  specializing  its  super¬ 
class,  thereby  adhering  to  its  semantics  |  Snyder|i986 1 . 

Though  Snyder  believes  that  it  can  be  useful  to  use  inheritance  without  it  being  part  of  the 
external  interface  of  a  class,  I  argue  that  the  second  definition  of  inheritance  is  more  appropriate. 
In  fact,  if  inheritance  is  being  used  merely  out  of  convenience  (e.g..  Vector  extending  Stack  in 
the  Java  standard  library),  then  it  is  very  likely  that  composition  is  a  more  appropriate  design 
|Bloch|20^|.  For  similar  reasons,  I  do  not  believe  a  language  should  allow  inheritance  without 


subtyping — e.g.,  C++  private  inheritance — as  this  can  always  be  implemented  using  a  helper 
class/brand  whose  visibility  is  restricted  using  the  language’s  module  system. 

Nevertheless,  if  one  takes  the  view  that  inheritance  choices  should  not  be  visible  to  sub¬ 
brands  (or  subclasses),  a  form  of  the  diamond  problem  can  arise  in  Unity.  In  particular,  suppose 
brand  D  extends  B  and  C,  C  extends  A,  and  B  extends  Object — a  valid  hierarchy  (recall  that 
condition  Bi  makes  a  special  exception  for  diamonds  involving  Object).  Now  suppose  that  B  is 
changed  to  extend  A,  and  the  maintainer  of  B  is  unaware  that  brand  D  exists.  Now  A,  B  and 
C  typecheck,  but  D  does  not.  Thus,  the  use  of  inheritance  can  invalidate  sub-brands,  which 
violates  Snyder’s  view  of  encapsulation. 

This  situation  highlights  the  fact  that,  in  general,  requires  should  be  favored  over  extends  if 
a  brand  is  intended  to  be  reused. 


Extensions 

It  would  be  possible  to  combine  the  proposed  solution  with  existing  techniques  for  dealing  with 
the  object  initialization  and  modular  multiple  dispatch  problems.  A  programmer  could  specify 
that  a  brand  C,  whose  constructor  takes  no  arguments,  may  be  the  root  of  a  diamond  hierarchy. 
Then,  one  would  use  the  Scala  solution  for  ensuring  that  C’s  constructor  is  called  only  once.  To 
solve  the  multiple  dispatch  problem,  if  C  is  the  owner  of  a  method  family  m,  the  typechecker 
would  ensure  that  m  contained  disambiguating  definitions  for  the  case  of  a  diamond — the  JPred 
and  Fortress  solutions. 

One  could  also  generalize  dynamically-dispatched  super  calls  so  that  they  are  chained,  as 
in  Scala  [Odersky  and  Zenger|||2005|.  In  Scala,  a  super  call  in  a  trait  is  dispatched  to  the  next 
type  in  the  linearization.  In  this  way,  traits  can  call  sibling  methods,  which  is  a  very  powerful 
composition  mechanism. 

Finally,  the  language  could  include  syntactic  sugar  to  ease  the  definition  of  concrete  brands. 
If  C  requires  B,  and  both  C  and  B  have  no-argument  constructors,  the  compiler  could  automat¬ 
ically  generate  a  brand  C$concrete  that  extends  both  C  and  B;  programmers  could  then  more 
easily  define  external  methods  that  dispatch  on  C$concrete. 


Multiple  Inheritance  vs.  Traits 

As  a  motivation  for  the  design  of  traits,  Scharli  et  al.  |Scharli  et  al.  2003)  identified  several 
problems  with  multiple  inheritance;  I  describe  here  how  our  proposed  solution  addresses  these 
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issues.  The  problems  are:  1)  conflicting  features:  methods  or  variables  are  inherited  along  two 
different  paths,  particularly  in  cases  of  diamond  inheritance;  2)  accessing  overriding  features:  us¬ 
ing  a  single  keyword  (such  as  super)  is  insufficient  to  unambiguously  identify  inherited  methods, 
so  one  must  explicitly  specify  the  superclass  (or  the  language  must  linearize  the  class  hierarchy); 
and  3)  factoring  out  generic  wrappers:  programmers  cannot  use  multiple  inheritance  to  write 
reusable  classes  that  wrap  methods  that  will  be  implemented  by  future  classes. 

The  first  of  these  problems,  conflicting  features,  is  solved  hyBi  (no  diamonds)  and  the  prop¬ 
erty  of  unique  method  names  (described  in  Sect.  2.4.3I1.  Problem  (2)  is  a  less  important  con¬ 
cern  in  a  statically  typed  language,  as  programmers  are  already  accustomed  to  specifying  brand 
names  for  types.  (This  does  indeed  make  it  slightly  more  difficult  to  move  methods  to  other 
brands,  but  refactoring  tools  make  this  task  trivial.)  Problem  (3)  is  solved  through  dynamically- 
dispatched  super  calls,  outlined  above  and  demonstrated  in  Sect. 
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3.6  Real-World  Examples 

In  this  section,  real-world  examples  (in  both  C++  and  Java)  are  presented  that  suggest  that  mul¬ 
tiple  inheritance,  and  diamond  inheritance  in  particular,  can  be  useful  for  code  reuse.  I  also 
describe  how  these  examples  can  be  expressed  in  Unity. 


3.6.1  C++  Examples 

I  examined  several  open-source  C++  applications  in  a  variety  of  domains  and  found  many  in¬ 
stances  of  virtual  inheritance  and  inheritance  diamonds.  Here  inheritance  diamonds  in  two 
applications  are  described:  Audacity^^  and  Guikachu.^"*^ 


Audacity 


Audacity  is  a  cross-platform  application  for  recording  and  editing  sounds.  One  of  its  main  stor¬ 
age  abstractions  is  the  class  BlockedSequence  (not  shown),  which  represents  an  array  of  au¬ 
dio  samples,  supporting  operations  such  as  cut  and  paste.  A  BlockedSequence  is  composed 
of  smaller  chunks;  these  are  objects  of  type  SeqBlock,  depicted  in  Fig.  3.10  (a).  One  sub¬ 


class  of  SeqBlock  is  SeqDataFileBlock,  which  stores  the  block  data  on  disk.  One  superclass  of 
SeqDataFileBlock  is  ManagedFile,  an  abstraction  for  temporary  files  that  are  de-allocated  based 
on  a  reference-counting  scheme.  Since  both  ManagedFile  and  SeqBlock  inherit  from  Storable  (to 
support  serialization),  this  forms  a  diamond  with  Storable  at  the  top. 

This  particular  diamond  can  be  easily  re-written  in  Unity  (Fig. 
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(b)),  since  the  sides  of 

the  diamond  (SeqBlock  and  ManagedFile)  are  already  abstract  classes.  (Compare  to  the  exam¬ 
ple  in  Fig.  I3.2I  where  new  concrete  brands  had  to  be  defined  for  the  sides  of  the  diamond.) 
Here,  we  would  simply  change  the  top  two  virtual  inheritance  edges  to  requires  edges,  and  make 
SeqDataFileBlock  inherit  from  Storable  directly.  This  may  even  be  a  preferable  abstraction;  while 


http://audacity.sourceforge.net/ 

http://cactus.rulez.org/projects/guikachu/ 
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(a)  (b) 


Figure  3.10:  An  inheritance  diamond  (a)  in  the  Audacity  application,  and  (b)  the  re-written 
class  hierarchy  in  Unity.  Abstract  classes  are  set  in  italic. 


Figure  3.11:  Two  inheritance  diamonds  (a)  in  the  Guikachu  application  and  the  classes  re¬ 
written  in  Unity  (b).  Abstract  classes  and  brands  are  set  in  italic. 


in  the  original  hierarchy  SeqDataFileBlock  is  serializable  by  virtue  of  the  fact  that  SeqBlock  is 
serializable,  in  the  new  hierarchy  we  are  making  this  relationship  explicit. 

Guikachu 

Guikachu  is  a  graphical  resource  editor  for  the  GNU  PalmOS  SDK.  It  allows  programmers  to 
graphically  manipulate  GUI  elements  for  a  Palm  application  in  the  GNOME  desktop  environ¬ 
ment.  In  this  application,  I  found  10  examples  of  diamonds  that  included  the  classes  Canvasitem, 
WidgetCanvasItem,  and  ResizeableCanvasItem.  Canvasitem  is  an  abstract  base  class  that  rep¬ 
resents  items  that  can  be  placed  onto  a  canvas,  while  objects  of  type  WidgetCanvasItem  and 
ResizeableCanvasItem  are  a  type  of  widget  or  are  resizeable,  respectively. 

Figure  |3.ii[a)  shows  two  of  these  10  diamonds,  formed  by  TextFieldCanvasItem  and 
PopupTriggerCanvasItem,  respectively.  The  hierarchy  was  likely  designed  this  way  because  there 
exist  GUI  elements  that  have  only  one  of  the  two  properties.  For  instance,  GraffitiCanvasItem 
and  LabelCanvasItem  (not  shown)  are  not  resizeable,  but  they  are  widgets.  In  contrast,  the  class 
FormCanvasItem  (not  shown)  is  resizeable,  but  is  not  a  widget. 

In  this  application,  I  also  observed  the  use  of  the  C++  virtual  inheritance  initializer  invoca¬ 
tion  mechanism:  TextFieldCanvasItem  (for  instance)  directly  calls  the  initializer  of  Canvasitem, 
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its  grandparent.  As  previously  described,  when  initializing  TextFieldCanvasItem,  the  initializer 
calls  from  WidgetCanvasItem  and  ResizeableCanvasItem  to  Canvasitem  are  ignored.  In  this  appli¬ 
cation,  the  initializers  happen  to  all  perform  the  same  operation,  but  this  invocation  semantics 
could  introduce  subtle  bugs  as  the  application  evolves. 


The  corresponding  Unity  brand  hierarchy  is  displayed  in  Fig.  [3.11  (b);  note  its  similar¬ 
ity  to  that  of  Fig.  |3.io|  (b).  Essentially,  the  virtual  inheritance  is  replaced  with  requires  and 
each  of  the  brands  at  the  bottom  of  the  diamond  inherit  from  all  three  of  WidgetCanvasItem, 
ResizeableCanvasItem,  and  Canvasitem.  The  Unity  design  has  the  advantage  that  constructor 
calls  do  not  occur  more  than  one  level  up  the  hierarchy,  and  no  constructor  calls  are  ignored. 

This  example  illustrates  how  a  program  could  be  translated  from  C++-style  multiple  inher¬ 
itance  to  Unity-style.  In  particular,  virtual  inheritance  would  be  replaced  by  requires,  and  new 
concrete  brands  would  be  defined  as  necessary  (changing  instantiations  of  the  now-abstract 
brand  to  instantiations  of  the  new  concrete  brand).  Note  that  constructor  calls  can  be  easily 
generated  for  the  new  concrete  brands,  as  C++  requires  a  call  from  the  bottom  of  the  diamond 
to  the  top  of  the  diamond  when  virtual  inheritance  is  used  (such  a  constructor  call  would  be 
necessary  for  the  new  concrete  brand,  as  it  would  directly  extend  the  brand  at  the  top  of  the 
diamond). 


3.6.2  Java  Example:  Eclipse  JDT 

The  Eclipse  JDT  (Java  Development  Tools)  provides  an  example  of  where  multiple  inheritance 
could  be  useful  for  Java  programs.  In  the  JDT,  every  AST  node  contains  structural  proper¬ 
ties.  A  node’s  structural  properties  allow  uniform  access  to  its  components.  Eor  example, 
DoStatement  has  two  fields  of  type  StructuralPropertyDescriptor:  EXPRESSION_PROPERTY  and 
BODY_PROPERTY.  To  get  the  expression  property  of  a  DoStatement  object,  the  programmer 
may  call  ds.getExpression( )  or  ds.getStructuralProperty(DoStatement.EXPRESSION_PROPERTY). 
Structural  property  descriptors  are  often  used  to  specify  how  AST  nodes  change  when  a  refac¬ 
toring  is  performed. 

Through  inspection  of  the  JDT  code,  I  found  that  there  was  a  great  deal  of  duplication 
among  the  code  for  getting  or  setting  a  node  property  using  the  structural  property  descrip¬ 
tors.  Eor  example,  19  AST  classes  (for  instance,  AssertStatement  and  ForStatement)  have 
getExpression/setExpression  properties.  As  a  result,  in  the  method  internalGetSetChildProperty 
(an  abstract  method  of  ASTNode),  there  are  19  duplications  of  the  following  code: 

if  (property  ==  EXPRESSION_PROPERTY)  { 
if  (get)  { 

return  getExpression( ) ; 

}  else  { 

set Expression ( (Expression)  child) ; 

return  null; 

J 

5  else  if  (property  ==  BODY_PROPERTY)  { 

...  //  code  for  body  property 

i 
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Additionally,  there  are  duplicate,  identical  definitions  of  the  EXPRESSION_PROPERTY  field. 
Without  a  form  of  multiple  inheritance,  however,  it  is  difficult  to  refactor  this  code  into  a 
common  location — DoStatement,  for  example,  already  has  the  superclass  Statement.  In  Unity, 
on  the  other  hand,  the  programmer  could  create  an  abstract  helper  brand  ExprPropertyHelper 
that  requires  ASTNode.  This  new  brand  would  contain  the  field  definition  and  an  override 
of  internalGetSetChildProperty.  DoStatement  would  then  inherit  from  both  Statement  and 
ExprPropertyHelper  and  would  have  the  following  body  for  internalGetSetChildProperty: 

if  (property  ==  BODY_PROPERTY) 

.  .  .  // code  for  body  property 

else 

ExprPropertyHelper . super. internalGetSetChildProperty (property,  get,  child) 

Finally,  this  is  a  scenario  where  mulitple  dispatch  would  be  beneficial.  The  framework  defines 
various  visitors  for  traversing  an  AST;  these  could  be  omitted  in  favor  of  external  methods  or 
multimethods,  which  are  more  extensible. 

Discussion 

Overall,  the  real-world  examples  suggest  that  multiple  inheritance  can  be  useful,  and  that  even 
diamond  inheritance  is  used  in  practice.  I  have  shown  that  the  inheritance  diamonds  can  be 
easily  translated  to  Unity  and  that  the  resulting  designs  offer  some  benefits  over  the  original 
ones. 


3.7  Formal  System 


2.5 


In  this  section,  I  describe  the  highlighted  portions  of  Sect. 

The  grammar  additions  needed  to  support  multiple  inheritance  are  relatively  minor 
(Fig.  |2.i5[  p.  [3^.  Brand  declarations  additionally  have  a  requires  clause  that  is  similar  to  the 
extends  clause: 


brand-declr.-  brand  B[r-,m-decl)  extends  Q,..., C„  requires  D 

External  method  blocks  (method-decl)  have  an  owner  brand  that  is  specified  before  the  method 
name.  Finally,  there  is  a  new  expression  form  that  has  already  been  described  in  the  examples: 

e::=  ...  I  e.B.super.^  ...  | 

This  is  the  syntactic  form  for  the  dynamically-dispatched  super  call,  which  was  illustrated  in  the 
AST  example. 


3.7.1  Static  Semantics 

This  section  describes  the  multiple  inheritance  changes  to  the  subtyping  judgement,  then  those 
regarding  the  typechecking  of  brands,  external  methods,  and  expressions. 
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Subtyping.  Only  the  subtype  judgement  (<)  has  an  additional  rule: 

B[r;Q)  extends  B  requires  Ci,..., C„  e  Z 

r  I-  Ml  <  M2 

- (Sub-Requires) 

rHB(Mi)<Q(M2) 

This  rule  provides  property  (2)  of  Def.[J!i|  B  branded  objects  are  subtypes  of  Ci  branded  objects. 
The  rule  is  safe,  due  to  properties  (1)  and  (3)  of  the  aforementioned  definition. 


Brand  declarations.  Recall  the  rules  for  typechecking  top-level  declarations:  Tp-Brand- 
Decl  and  Tp-Ext-Method  (Fig.  2.18  p.|^.  For  typechecking  brand  declarations,  the  auxiliary 
judgement  inherit-ok  was  used: 


(Tp-Inherit) 

©CeZ  ©DeZ  @  D,  ^  C  (Vie  l..m) 

®  V  F  j.  i  *  j.  ID'.  Ci  Ez  D'  and  Cj  Ez  D'  [D'  *  Object) 

®  Q  requires  Fe  Z  implies  3A:.  Ez  F  or  Dj;  Ez  F  (Vrel..n) 
®  D;  requires  F' e  Z  implies  Cjt  Ez  F' or  Ez  F'  (Vz€l..m) 
®  V z,  j.  yq.  rntypej-iq,  Ci)  =  p  and  mtypej^iq,  Cj)  =  p'  implies  z  =  j 
Hz  B  extends  Cl,. ..,C„  requires  Di,..., Dm  e  Z  inherit-ok 


That  judgement  ensures  that  the  declared  superclasses  exist  in  Z,  that  there  are  no  inheritance 
diamonds  (premise  4),  that  requires  is  propagated  down  the  inheritance  hierarchy  (premises  5 
and  6),  and  that  there  are  no  methods  with  the  same  name  in  two  inherited  classes. 

For  typechecking  the  bodies  of  internal  methods  {decl  body-ok),  the  requires  clause  is  taken 
into  account  (Fig. 


2.20|  p.|44 


(Brand-Decl-Body) 

fieldTypej. (D)  =  a'  this  :  B(M;), fields  :  cr  a  u'  h^  ei  ■  t,- 

brand  B[o]qi  B{Mi) :  t,-  =  e,-  extends  C  requires  D  body-ok 


The  second  premise  looks  up  the  field  type  of  F’s  required  brands,  naming  them  (the  list)  o' . 
Then,  when  typechecking  the  method  body  (the  third  premise),  we  can  safely  assume  that  the 
fields  of  the  receiver  (the  special  variable  fields)  actually  contain  these  required-brand  fields  o' . 
This  is  sound  for  the  same  reason  that  the  subtyping  rule  Sub-Requires  is  sound:  property  (1) 
of  Def.  3.1  ensures  that  objects  cannot  be  instantiated  from  a  brand  that  has  a  requires  clause. 


(This  property  is  enforced  when  typechecking  the  object-instantiation  expression,  described  in 
a  subsection  below.) 


’^^Note  that  this  property  will  always  hold  if  an  elaboration  of  the  form  outlined  in  Sect. 


2.4.3 


is  used. 
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External  method  blocks. 

method  family: 


The  rule  Tp-Ext-Method  (Fig.|2.i8  p.[4^  typechecks  an  external 


(Tp-Ext-Method) 

®  Object  ®  C  distinct  ®  Q  Ej;  B  (Viel..n) 

®  If  z  C.q  internal  ®  Z'  =  Z,  method  B.qiC.q  ■  p)  ®  C.q  ■  p  override-ok 

Z  I-  method  B.qiC.q :  p)  ok 


Here,  premise  (1)  enforces  the  first  part  of  condition  £3:  the  owner  brand  cannot  be  Object.  The 
second  part  of  condition  £3  (each  method  declaration  is  defined  on  a  sub-brand  of  the  owner 
brand)  is  enforced  by  premise  (3). 


Expressions.  The  changes  to  the  rules  for  typechecking  expressions  are  fairly  minor.  The 
first  premise  of  Tp-New-Obj  (Fig.  [2.21]  p.  45 1  enforces  property  (1)  of  Def.  [3. i[— brands  with  a 
requires  clause  may  not  be  instantiated. 

The  rule  Tp-With  adds  new  simple  to  qualified  mappings  after  an  object  has  been  created. 
To  simplify  the  formal  system,  the  mtype  judgement  does  not  consider  required  brands,  only 
extended  brands.  This  does  not  cause  any  problems  for  expressiveness,  however,  as  a  brand  can 
always  be  coerced  to  its  required  brand  via  the  subsumption  rule. 

But,  when  setting  up  the  mapping,  we  may  wish  to  add  methods  from  both  inherited  and 
required  brands.  Thus,  the  rule  permits  any  mapping  for  which  there  exists  mtype  for  the  brand 
itself  or  one  of  its  required  brands: 

(Tp-With) 

ri-e:B(M)  B  requires  DeZ  UtM  n  distinct 
3C e  {B,D}.  mtype^iqi,C)  ■  pi  (Vz  e  l..n) 


r  I-  e  with  Hi 


_  Z€l..f2  .  Ty  f  A  /T  M  Z€l..fZ'v 

■qi  ■■BiM,ni.pi  ] 


The  final  multiple  inheritance  addition  is  rule  Tp-Invoke-Super  (also  in  Fig.  2.2i|  which 


typechecks  the  dynamically-dispatched  super  call.  Here,  we  check  that  the  brand  qualifier  C  is 
require’d  by  the  object’s  brand  and  perform  an  mtype  lookup  using  C.  Note  the  similarity  of  Tp- 
Invoke-Super  to  Tp-Invoke-Nom,  which  typechecks  (ordinary)  qualified  method  invocation. 


3.7.2  Dynamic  Semantics 


There  are  fewer  changes  to  the  dynamic  semantics:  there  is  a  congruence  and  computation  rule 
for  dynamically-dispatched  super  calls.  (Fig. 


2.25 


The  congruence  rule  is  standard;  the 


computation  rule,  E-Super-Invk-Val,  is: 


3  unique  C'.  super ^^iB  as  C)  =  C'  lookup ^iq,  C')  =  e 

Biv;  n  ^  ^j.C.super.^  1 — {B(p;  n  ^  ^)/this,  rz/fields}  e 


Here,  we  use  (the  unique  result  of)  the  super  auxiliary  judgement  to  find  the  appropriate  class 
C';  the  method  q  is  then  looked  up  within  C' .  This  auxiliary  judgement  is: 
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do'  Ea  C.  B  extends  D'  €  A  B  extends  £  e  A 
B  extends  De  A  DEaC  3k.super^[Ek  as  C)  =  D 

super ^[B  as  C)  =  D  super ^{B  as  C]  =  D 

That  is,  super  finds  the  first  super-brand  of  B  that  is  also  a  subtype  of  C  (i.e.,  the  first  parent  that 
fulfills  the  requires  C  enforced  by  Tp-Invoke-Super).  The  judgement  super  uses  the  sub-brand 
judgement  on  runtime  contexts,  Ea>  this  latter  judgement  mirroring  Ex  with  the  exception  that 
A  is  used  rather  than  Z: 


Definition  3.2  (Ea  judgement). 

The  judgement  B  Ea  C  is  defined  by  inference  rules  identical  to  those  of  B  Ex  C  (i.e.,  Sub-Brand- 
Refl,  Sub-Brand-Trans,  and  Sub-Brand-Decl  in  Fig.  2.i6|l,  except  that  the  runtime  context  A 
is  used  instead  of  Z. 


3.7.3  Modularity 

As  mentioned  in  Sect.  |i.i[  modular  typechecking  is  an  essential  property  for  a  practical  lan¬ 
guage.  In  its  absence,  scalability  and  extensibility  issues  will  immediately  arise,  particularly  when 
multiple  developers  are  working  on  a  project.  With  a  modular  type  system,  programmers  can  be 
assured  that  their  modules  will  typecheck  when  incorporated  into  a  larger  program  and  clients 
of  a  module  can  be  shielded  from  changes  to  a  module’s  internals,  when  those  changes  do  not 
affect  its  interface. 

I  define  a  typechecking  algorithm  as  modular  if  each  module  in  the  program  can  be  type- 
checked  using  only  the  interfaces  of  the  other  modules  on  which  it  statically  depends.  Moreover, 
if  a  module  typechecks  in  isolation,  this  fact  should  not  change  when  it  is  combined  with  other 
modules.  From  this  it  follows  that  the  linker  cannot  perform  any  typechecking;  it  mainly  per¬ 
forms  a  consistency  check  to  ensure  that  a  definition  is  present  for  all  modules  that  have  been 
assumed  to  exist  in  the  program. 

In  the  Unity  calculus,  each  top-level  declaration  (i.e.,  brand  or  external  method)  is  assumed 
to  be  in  its  own  module.  Recall  that  top-level  declarations  contain  a  context  Z  which  include  all 
definitions  on  which  the  declaration  statically  depends.  This  context  is  of  key  importance  for 
the  modularity  proof,  as  Z  is  precisely  the  interfaces  of  the  other  modules  for  which  the  module 
in  question  assumes  a  definition  exists. 

From  this  it  follows  that  typechecking  is  modular  if  each  declaration  is  typechecked  under 
its  declared  context  Z  and  if  the  declaration  will  always  typecheck  under  any  context  Z'  that 
contains  at  least  all  the  declarations  in  Z. 

The  calculus  has  been  carefully  designed  so  that  the  proof  of  modularity  is  straightforward: 

Theorem  3.1.  Typechecking  top-level  elements  declarations  decl  is  modular;  i.e.,  typechecking 
such  elements  only  involves  examining  the  signatures  Z  on  which  decl  statically  depends. 

Proof.  Follows  from  the  fact  that  top-level  elements  are  typechecked  under  their  declared  con¬ 
text  Zq.  The  only  rules  that  examine  the  entire  linearized  program  context  Z  are  Tp-Decl-Ok 
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(Sigma -Wf-Base) 

(Sigma-Wf-Decl) 

decl-type^^^g  tZ  Z  ok  Z  1-  decl-type  ok 

•  ok 

Z,  decl-type  ok 

Figure  3.12:  Well-formed  judgement  for  static  context  Z 

and  Tp-Expr-Ok,  in  the  premise  Z  2  Zq.  This  step  is  analogous  to  a  linking  phase  in  which  im¬ 
ported  declarations  are  resolved.  Since  checking  set  inclusion  does  not  involve  typechecking  of 
any  kind,  this  check  adheres  to  the  definition  of  modular  typechecking.  □ 


3.7.4  Type  Safety 

The  full  proof  of  type  safety  is  provided  in  Appendix]^  the  main  results  are  summarized  here. 
First,  we  define  the  properties  of  well-formed  context  Z  (Fig.  3.12I,  which  includes  some  of  the 
same  properties  checked  by  Tp-Decl-Ok.  Declarations  must  have  unique  names,  and  each  dec¬ 
laration  must  be  well-typed  under  the  context  of  the  types  that  precede  it. 

The  type  safety  theorems  assume  a  correspondence  between  the  runtime  context  A  and  the 
brand  and  method  context  Z.  This  ensures  that  the  runtime  context,  which  does  not  contain 
type  information,  is  consistent  with  the  static  typing  context,  which  does  not  contain  any  code. 
Formally,  this  correspondence  is  defined  as  follows: 


Definition  3.3  (Context  consistency  relation). 

The  judgement  A  :  Z  is  defined  by  the  following  inference  rules: 

(Delta-Wf-Brand) 

Z  =  Zq,  brand  :  B[Mi)  =>  T;  extends  C  requires  D 

(Delta-Wf-Empty)  Ao  :  Zq  fieldTypej;  (D)  =  a 

this :  B(M,),  fields :  O' A  (f  i-x  et  :t,-  (Vz  e  L.n) 

•  :  •  Ao,B(^j- =  P; extends  C  :  Z 

(Delta-Wf-Method) 

Z  =  Zo,  method  qiqiBiiMi)  =>  t/  Aq  :  Zq 

this  •■Bi(Mi]  i-x  ei'.Ti  (VzeL.zz) 

Ao,  method  =  :  Z 


Type  safety  is  proved  using  the  standard  progress  and  preservation  theorems.  These  theo¬ 
rems  each  depend  on  weakening  properties  of  the  various  judgements  under  a  larger  context  Z. 
For  example,  we  have  the  following: 

Lemma  3.1  (Weakening  for  sub-brand  judgement). 

If  Zq  ok  and  B  Exq  C  and  Z  ok  and  Z  2  Zq  then  B  Ex  C. 
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Proof.  See  proof  of  Lemma|A.3|(p.|i3o|.  □ 

A  similar  weakening  property  holds  for  the  subtyping  and  typing  relations.  Additionally,  the 
decl-type  ok  judgement  can  be  weakened  so  that  we  have  the  following: 

Lemma  3.2  (Declarations  are  welhtyped  under  their  containing  context). 

If  Z  ok  and  decl-type  e  Z  then  Z  1-  decl-type  ok. 

Proof.  See  proof  of  Lemma|A.i4|(p.|i35|l.  □ 

The  proof  of  the  above  lemma  makes  use  of  condition  Ei — since  external  method  definitions  q 
must  all  appear  in  the  same  block  that  the  family  q  is  introduced,  extensions  of  the  context  Z 
cannot  contain  new  (external)  definitions  for  q. 

An  auxiliary  lemma  is  used  for  the  weakening  lemmas,  which  allows  us  to  conclude  that 
two  brands  B  and  C  must  have  a  common  ancestor  that  is  a  strict  subtype  of  Object  if  an  mtype 
derivation  exists  for  both  B  and  C  for  the  same  method  q: 

Lemma  3.3  (Common  method  implies  common  ancestor). 

If  Z  ok  and  mtype^{q,B)  and  mtype^iq,  C)  then  there  exists  some  D  i=  Object  such  that  B  D 
and  C  Ex  D. 


Proof.  See  proof  of  Lemma|A.2|(p.|i3o|.  □ 

Conditions  E1-E3  are  all  used  in  the  proof  of  this  lemma. 

Progress 

For  progress,  we  prove  a  lemma  that  states  that  if  method  q  has  type  p  in  B  (either  declared 
or  inherited),  then  a  runtime  context  A  consistent  with  the  static  context  Z  contains  a  unique 
method  body  for  q: 

Lemma  3.4  {lookup  defined  on  well-typed  objects). 

If  Z  ok  and  mtype^iq,  B]  -  p  and  A  :  Z,  then  lookup /^{q, B)  -  e,  for  some  unique  e. 

Proof.  By  induction  on  the  derivation  mtype^iq,  B).  See  proof  of  Lemma[A.3i|(p.[i3^.  □ 

This  lemma  has  several  interesting  cases.  For  internal  and  external  methods,  we  use  the  fact  that 
an  internal  and  external  method  cannot  both  exist  for  a  particular  brand — condition  £2.  For  the 
inductive  step,  we  use  the  fact  that  a  class  cannot  inherit  a  method  with  the  same  name  from 
two  distinct  classes — premise  (7)  of  Tp-Inherit.  For  the  inductive  case  MType-Inh,  we  use 
condition  £3  to  show  that  at  most  one  external  method  definition  is  inherited  from  superclasses 
(i.e.,  the  same  external  method  cannot  be  defined  for  two  different  superclasses  of  a  class  C). 
Finally,  because  of  the  no-diamond  property  (condition  Bi),  the  same  internal  method  cannot 
be  inherited  from  two  distinct  superclasses. 


3-7 ■  Formal  System 


89 


Now  we  are  ready  to  prove  the  standard  progess  theorem.  Note  that  this  theorem  has  a  cor¬ 
responding  lemma  for  expressions,  Lemma[A.35|(p.[i4i]l,  where  we  prove  the  more  interesting 
cases.  The  most  interesting  case  is  method  invocation,  which  simply  uses  the  previous  lemma. 

Theorem  3.2  (Progress  [programs]). 

If  Z  ok  and  Z  1-  p  ok,  then  one  of  the  following  cases  holds: 

1.  pis  a  value;  or 

2.  for  any  A  such  that  A  :  Z,  there  exist  p'  and  A'  such  that  p  \  A  1 — >  p'  I  A'. 


Proof.  See  proof  of  Theorem|A.i|(Sect.|A.4  p.  143I1. 


□ 


Preservation 

For  proving  preservation,  we  first  prove  standard  inversion  lemmas  for  subtyping  and  typing 
(Lemmas |A.28|and|A.29|.  Next,  we  prove  a  lemma  that  states  that  the  result  of  mtype  is  unique: 

Lemma  3.5  {mtype  is  a  function). 

If  Z  ok  and  mtype^iq,  B)  -  pi  and  mtype^iq,  B)  -  p2,  then  pi  =  p2. 


Proof.  By  simultaneous  induction  on  the  two  mtype  derivations.  See  proof  of  Lemma  IA.39 
(p.|i43|. 


□ 


The  lemma  is  proved  using  conditions  E1-E3,  as  well  as  the  no-diamond  property  (condition 
Bi). 

The  next  key  preservation  lemma  proves  that  the  result  of  the  lookup  judgement  is  consistent 
with  the  result  of  mtype: 

Lemma  3.6  (Result  of  lookup  is  well-typed). 

If  Z  ok  and  A  :  Z  and  mtype^iq,  C)  -  and  lookup ^^iq,  C]  -  eo,  then 

this : (Tc, fields : oy  eo'-r. 

for  some  ac  and  oy  such  that  C[N)  <  ac  and  fieIdWithReqj;(C)  <  ay. 

Proof.  By  induction  on  lookup^iq,  C).  See  proof  of  Lemma|A.4o|(p.[i44|.  □ 

The  base  cases  are  straightforward,  but  the  inductive  case  (Lookup-Inh)  makes  use  of  the  mtype 
uniqueness  lemma  above  (Lemma [3. sf,  to  map  a  lookup  derviation  to  a  corresponding  mtype 
derivation. 

Now  we  are  ready  to  state  the  main  preservation  theorem: 

Theorem  3.3  (Preservation  [programs]). 

If  Z  ok  and  Z  1-  p  ok  and  A  :  Z  and  p  |  A  1 — >  p'  \  A',  then  there  exists  a  Z'  such  that  (a)  Z'  ok; 
and  (b)  A'  :  Z';  and  (c)  Z'  1-  p'  ok. 


Proof.  See  proof  of  Theorem |A^ (Sect.  |A^  p.  149I1. 


□ 
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As  with  progress,  preservation  also  has  a  lemma  for  of  expressions  (Lemma[A.42[  p.|i45|,  where 
most  of  the  interesting  reasoning  lies,  particularly  the  cases  of  method  invocation. 


3.8  Related  Work 


Here,  I  revisit  the  JPred  and  Fortress  solutions  and  describe  other  closely  related  work:  mixins. 


traits,  and  stateful  traits.  Comparison  to  additional,  less  closely  related  work  appears  in  Sect.  5.4 


JPred  and  Fortress 


As  mentioned  in  Sect.  [3^  JPred  |  Frost  and  Millstein  2006)  and  Fortress  [Allen  et  al.]2007|  per¬ 
form  modular  multimethod  typechecking  by  requiring  that  programmers  provide  disambiguat¬ 
ing  methods,  some  of  which  may  never  be  called.  However,  the  JPred  and  Fortress  dispatch 
semantics  may  be  more  expressive  than  that  of  Unity.  In  Unity,  recall  that  in  the  class  hierarchy 
Fig.  3.2  the  abstract  class  InputStream  may  not  override  a  Stream  method  externally,  because 


it  is  not  a  subclass  of  Stream.  In  contrast,  if  this  hierarchy  were  expressed  in  JPred  or  Fortress, 
a  multimethod  defined  on  Stream  could  be  overridden  by  either  InputStream  or  OutputStream. 
Note,  however,  that  programmers  can  achieve  a  similar  effect  in  Unity  by  having  concrete  classes 
call  helper  methods  (which  can  be  defined  externally)  in  the  abstract  classes. 


Mixins 


Mixins,  also  known  as  abstract  subclasses,  provide  many  of  the  reuse  benefits  of  multiple  in- 


heritance  while  fitting  into  a  single  inheritance  framework  [Bracha  and  Cook|i99ot  Ancona  and 

Zucca 

i996j|Flatt  et  al.  1998I  Findler  and  Flatt 

1999  Ancona  et  al.|2003l|Bettini  et  al.  2004] .  While 

mixins  allow  defining  state,  they  have  two  drawbacks:  they  must  be  explicitly  linearized  by  the 
programmer  and  they  cannot  inherit  from  one  another  (though  most  systems  allow  expressing 
implementation  dependencies,  such  as  abstract  members).  If  mixin  inheritance  were  allowed, 
this  would  be  essentially  equivalent  to  Scala  traits,  which  do  have  the  object  initialization  prob¬ 
lem.  Additionally,  the  lack  of  inheritance  has  the  consequence  that  mixins  do  not  integrate  well 
with  multiple  dispatch;  multiple  dispatch  requires  an  explicit  inheritance  hierarchy  on  which  to 
perform  the  dispatch. 


Traits 


Traits  were  proposed  as  a  mechanism  for  finer-grained  reuse,  to  solve  the  reuse  problems  caused 
by  mixins  and  multiple  inheritance  [Ducasse  et  al.[2006|  [Fisher  and  Rep'^|2004[  Oder  sky  and 
Zenger  2005}.  In  particular,  the  linearization  imposed  by  mixins  can  necessitate  the  definition 
of  numerous  “glue”  methods  | Ducasse  et  al.||2006|.  This  design  avoids  many  problems  caused 
by  multiple  inheritance  since  fields  may  not  be  defined  in  traits. 

Unfortunately,  this  restriction  results  in  other  problems.  In  particular,  non-private  accessors 
in  a  trait  negatively  impact  information  hiding:  if  a  trait  needs  to  use  state,  this  is  encoded  using 
abstract  accessor  methods,  which  must  then  be  implemented  by  the  class  composed  using  the 
trait.  Consequently,  it  is  impossible  to  define  “state”  that  is  private  to  a  trait — by  definition,  all 
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classes  reusing  the  trait  can  access  this  state.  (We  will  see  an  example  of  this  in  Sect.|3.5|below.) 
Additionally,  introducing  new  accessors  in  a  trait  results  in  a  ripple  effect,  as  all  client  classes 
must  now  provide  implementations  for  these  methods  |Bergel  et  al.  20o8|,  even  if  there  are  no 
other  changes. 

In  contrast.  Unity  allows  a  brand  to  multiply  inherit  other  brands,  which  may  contain  state. 
In  particular,  a  brand  may  extend  other  concrete  brands,  while  in  trait  systems,  only  traits  may 
be  multiply  inherited. 


Stateful  Traits 


Stateful  traits  [Bergel  et  al.  20o8|  were  designed  to  address  the  aforementioned  problems  with 
stateless  traits.  But,  as  previously  mentioned,  this  language  does  not  address  the  problem  of  a 
correct  semantics  for  object  initialization  in  the  presence  of  diamonds.  Additionally,  stateful 
traits  do  not  address  the  information  hiding  problem,  as  they  have  been  designed  for  maximal 
code  reuse.  In  this  design,  state  is  hidden  by  default,  but  clients  can  “unhide”  it,  and  may  have  to 
resort  to  merging  variables  that  are  inherited  from  multiple  traits.  While  this  provides  a  great 
deal  of  flexibility  for  trait  clients,  this  design  does  not  allow  traits  to  define  private  state. 


3.9  Conclusions 


In  this  chapter,  I  have  shown  how  a  small  modification  to  the  rules  of  traditional  multiple  in¬ 
heritance  can  reap  great  rewards  in  terms  of  program  reasoning.  In  particular,  the  problems 
of  object  initialization  and  modular  typechecking  of  external  methods  disappear  in  a  language 
that  disallows  diamond  inheritance.  I  have  also  shown  that  the  expressiveness  of  diamond  in¬ 
heritance  can  be  recovered  through  use  of  the  requires  construct,  even  in  real-world  examples. 

The  type  safety  of  the  language  was  summarized,  affirming  hypothesis  The  modularity 
proof  in  Sect.  3.7.3  is  the  evidence  for  hypothesis  |V[  The  multiple  inheritance  design  and  the 


comparison  to  related  systems  (Java-style  multiple  interface  inheritance,  mixins  and  traits)  il¬ 
lustrated  the  expressiveness  of  the  Unity  design  (Sect.[J^,  a  design  that  satisfies  hypothesis [Vl| 
Finally,  the  C++  examples  showed  the  feasibility  of  a  systematic  translation  of  diamond  inheri¬ 
tance  into  Unity  multiple  inheritance,  which  supports  hypothesis  |VII[ 
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Chapter  4 

Empirical  Results 


“Give  your  evidence,”  said  the  King;  “and  don’t  be  nervous,  or  I’ll  have 
you  executed  on  the  spot.” 

Lewis  Carroll  (Alice’s  Adventures  in  Wonderland) 


In  this  dissertation,  I  have  proposed  a  combination  of  nominal  and  structural  subtyping,  in  order 
to  obtain  the  flexibility  and  expressiveness  benefits  of  the  latter  typing  discipline.  To  support  the 
claim  that  structural  subtyping  is  beneficial,  I  presented  examples  and  applications  to  real-world 
situations  (Sections|2.2|and[2^. 

Many  in  the  research  community  agree  with  this  view;  as  mentioned  in  Chapter[i]  structural 


subtyping  has  been  extensively  studied  in  a  formal  setting  (e.g.,  |Cardelli|i988|  Bruce  et  al.||2003 


Fisher  and  Reppyfiggg}  Leroy  et  al.||2004|  Malayeri|2009a|).  And  yet,  structural  sub  typing  is  not 


used  in  any  mainstream  object-oriented  programming  language — perhaps  due  in  part  to  the 
lack  of  evidence  of  its  utility.  Accordingly,  I  considered  the  following  question:  what  empirical 
evidence  could  show  that  structural  subtyping  can  be  beneficial?^ 


4.1  Empirical  Criteria 


Let  us  consider  the  characteristics  that  a  nominally-typed  program  might  exhibit  that  would 
indicate  that  it  could  benefit  from  structural  subtyping.  First,  the  program  might  systematically 
make  use  of  a  subset  of  methods  of  a  type,  with  no  nominal  type  corresponding  to  this  method 
set.  A  particular  such  implicit  type  might  be  used  repeatedly  throughout  the  program.  Struc¬ 
tural  subtyping  would  allow  these  types  to  be  easily  expressed,  without  requiring  that  the  type 
hierarchy  of  the  program  change.  This  is  particularly  beneficial  when  a  nominal  hierarchy  can¬ 
not  be  changed  (due  to  lack  of  access  to  or  control  of  the  applicable  source  code),  as  changing  a 
nominal  hierarchy  generally  requires  changes  to  the  intended  subtypes.  For  example,  in  Java,  to 
express  the  fact  that  class  C  implements  interface  /,  C’s  source  must  be  modified.^ 


^The  primary  technical  contributions  of  this  chapter  appeared  in  |Malayeri  and  Aldrich  2009b  . 

^This  is  no  accident;  fully-general  retroactive  subtyping  leads  to  inherent  modularity  problems,  particu¬ 
larly  when  nominal  types  can  be  used  in  runtime  dispatch.  See  Sect. 
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Second,  there  might  be  methods  in  two  different  classes  that  share  the  same  name  and  per¬ 
form  the  same  operation,  but  that  are  not  contained  in  a  common  nominal  supertype.  There 
are  a  number  of  reasons  why  such  a  situation  might  occur,  such  as  oversight  on  the  part  of 
the  original  designers.  This  is  particularly  likely  when  the  original  code  did  not  need  to  make 
use  of  the  implicit  interface  induced  by  these  common  methods.  Alternatively,  perhaps  such  a 
need  did  exist,  but  programmers  resorted  to  code  duplication  rather  than  refactoring  the  type 
hierarchy — possibly  because  the  source  code  was  not  accessible  or  could  not  be  changed.  On 
the  other  hand,  with  structural  subtyping,  the  two  classes  in  question  would  automatically  share 
a  common  supertype  consisting  of  the  shared  methods. 

Or,  programs  might  use  the  Java  reflection  method  Class. getMethod  ( )  to  call  a  method  with 
a  particular  signature  in  a  generic  manner.  For  instance,  we  may  wish  to  write  a  method  m 
that  can  be  passed  as  an  argument  any  object  that  contains  a  “String  getNameO”  method.  In 
nominally  typed  languages,  this  can  generally  be  achieved  only  through  dynamic  means  such  as 
reflection;  in  contrast,  structural  subtyping  provides  such  a  capability  in  a  statically-checkable 
manner. 

Finally,  suppose  a  programmer  is  faced  with  the  challenge  of  writing  a  class  C  that  only 
supports  a  subset  of  its  declared  interface  /.  But,  such  a  super-interface  does  not  exist  and  cannot 
be  defined,  perhaps  due  to  library  use.  One  possible  implementation  strategy  is  simply  throw 
an  exception  (e.g.,  UnsupportedOperationException)  when  one  of  C’s  unimplemented  methods 
is  called.  In  contrast,  with  structural  subtyping,  the  intended  structural  super-interface  could 
simply  be  used. 

With  all  of  these  characteristics  in  mind,  I  performed  several  manual  and  automated  anal¬ 
yses  on  (up  to)  29  open-source  Java  programs.  In  the  case  of  manual  analyses,  a  subset  of  the 
subject  programs  was  considered.  Each  of  these  analyses  aimed  to  answer  one  question:  are 
nominally- typed  programs  using  implicit  structural  types?  The  result  was  that  indeed  they  were; 
representing  these  types  explicitly  could  therefore  produce  desirable  characteristics,  such  as  in¬ 
creased  code  reuse  and  decreased  maintenance  effort. 


In  the  empirical  evaluation,  answers  to  the  following  questions  were  sought: 


1.  Does  the  body  of  a  method  use  only  a  subset  of  the  methods  of  its  parameters?  If  so, 
structural  types  could  ease  the  task  of  making  the  method  more  general.  (Sect.  [4^ 


2. 


If  structural  types  are  inferred  for  method  parameters,  do  there  exist  inferred  types  that 
are  used  repeatedly,  suggesting  that  they  represent  a  meaningful  abstraction?  (Sect.  4.3.3I 


3.  How  many  methods  always  throw  “unsupported  operation”  exceptions?  In  such  cases, 
the  enclosing  classes  support  a  structural  supertype  of  the  declared  class  type;  the  latter 
contains  all  of  the  declared  and  inherited  methods  of  the  class  (regardless  of  their  imple¬ 
mentation,  or  lack  thereof).  (Sect.  [4^ 


4.  What  is  the  nature  and  frequency  of  common  methods'?  That  is,  sets  of  methods  with 
identical  names  and  signatures,  but  that  are  not  contained  in  any  common  supertype  of 
the  enclosing  classes.  (Sect  [4^5^ 

5.  How  many  common  methods  represent  an  accidental  name  dash?  (Sect [4.5.^ 

6.  Can  structural  subtyping  reduce  some  types  of  code  duplication?  (Sect.  [4^5^ 
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7.  Is  there  empirical  evidence  of  a  potential  synergy  between  structural  subtyping  and  ex¬ 
ternal  methods?  (Sect.  [4^ 

8.  Do  programs  use  reflection  where  structural  types  would  be  preferable?  (Sect.  [4^ 

Thus,  a  variety  of  facets  of  existing  programs  were  considered.  While  none  of  these  aspects 
is  conclusive  on  its  own,  taken  together,  the  answers  to  the  above  questions  provide  evidence 
that  even  programs  written  with  a  nominal  subtyping  discipline  could  benefit  from  structural 
subtyping.  This  study  provides  initial  answers  to  the  above  questions;  further  study  is  needed  to 
fully  examine  all  aspects  of  some  questions,  particularly  questions[i]and|^  Additionally,  as  men¬ 
tioned  in  previous  chapters,  one  must  bear  in  mind  that  structural  subtyping  is  not  always  the 
appropriate  solution;  there  do  exist  situations  in  which  nominal  subtyping  is  more  appropriate 

(Sect.iri). 

To  my  knowledge,  this  is  the  first  systematic  corpus  analysis  to  determine  the  benefits  of 
structural  subtyping.  The  contribution  of  this  chapter  are:  (1)  identification  of  a  number  of 
characteristics  in  a  program  that  suggest  the  use  of  implicit  structural  types;  and  (2)  results 
from  automated  and  manual  analyses  that  measure  the  identified  characteristics. 


4.2  Corpus  and  Methodology 


For  this  study,  the  source  code  of  up  to  29  open-source  Java  applications  were  examined  (version 


numbers  of  the  applications  are  provided  in  Appendix  B.i  I.  The  full  set  of  subject  programs  were 
used  for  the  automated  analyses,  while  (while  for  practical  considerations)  manual  analyses  were 
performed  on  various  subsets  of  these  (ranging  from  2  to  8  members).  The  applications  were 
chosen  from  the  following  sources:  popular  applications  on  SourceForge,  Apache  Foundation 
applications,  and  the  DaCapo  benchmark  suite.^ 

The  full  set  of  programs  range  from  12  kLOC  to  161  kLOC,  programs  that  were  selected 
based  on  size,  type  (library/framework  vs.  sealed  applications"’^)  and  domain  (selecting  for  va¬ 
riety).  For  some  of  the  manual  analyses,  I  favored  applications  with  which  I  was  familiar  (as 
this  aided  analysis),  but  I  also  aimed  for  variety  in  both  application  type  and  domain.  All  of  the 
manual  analyses,  including  the  subjective  analyses,  were  performed  by  one  observer  only — the 
author.  The  methodology  for  each  analysis  is  described  in  the  corresponding  section;  further 
details  are  available  in  Appendix |B.2[ 


4.3  Inferring  Structural  Types  for  Method  Parameters 


It  is  considered  good  programming  practice  to  make  parameters  as  general  as  the  program  al¬ 
lows.  Bloch,  for  example,  recommends  favoring  interfaces  over  classes  in  general — particularly 
so  in  the  case  of  parameter  types  |Bloch|^oi|.  An  analogous  situation  arises  in  the  generic 


programming  community,  where  it  is  recommended  that  generic  algorithms  and  types  place  as 


3  http://dacapobench.org/ 

■^Fiere  I  define  a  sealed  application  as  a  complete  program  that  is  not  intended  to  be  directly  reused. 
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few  requirements  as  possible  on  their  type  parameters  (e.g.,  what  methods  they  should  support) 
|Musser  and  Stepanov  19^ . 

Bloch  acknowledges  that  sometimes  an  appropriate  interface  does  not  exist.  For  example, 
class  java. util. Random  implements  only  one  (empty)  marker  interface.  In  such  a  case  the  pro¬ 
grammer  is  forced  to  use  classes  for  parameter  types — even  though  it  is  possible  that  multiple 
implementations  of  the  same  functionality  could  exist  |Bloch||20oi  |.  This  is  a  situation  where 
structural  subtyping  could  be  beneficial,  as  it  allows  programmers  to  create  supertypes  after- 
the-fact. 

As  it  is  impossible  to  retroactively  implement  interfaces  in  Java,  I  hypothesized  that  method 
parameter  types  are  often  overly  specific,  and  sought  to  determine  both  (1)  the  degree  and  (2) 
the  character  of  over-specificity.  To  answer  question  (1),  an  automated  whole-program  analysis 
to  infer  structural  types  for  method  parameters  was  performed.  Methodology  and  quantitative 
results  are  described  in  Sect. 


4.3.1 


To  properly  interpret  this  data,  however,  we  must  consider 
question  (2).  Accordingly,  the  inferred  structural  types  from  the  previous  analysis  were  manu¬ 
ally  examined  and  the  following  qualitative  question  was  considered:  would  changing  a  method 
to  have  the  most  general  structural  type  potentially  improve  the  method’s  interface  (Sect.  4.3.2 1? 
Across  all  applications,  the  occurrences  of  inferred  structural  types  that  were  supertypes  of 
classes  and  interfaces  of  the  Java  Collections  Library  were  enumerated.  Of  these,  in  Sect. 


4.3.3 


those  structural  types  that  a  client  might  plausibly  wish  to  implement  while  not  simultaneously 
implementing  a  more  specific  nominal  type  (e.g..  Collection,  Map,  etc.)  are  presented. 


4.3.1  Quantitative  Results 

The  analysis  infers  structural  types  for  method  parameters,  based  on  the  methods  that  were 
actually  called  on  the  parameters.  (For  example,  a  method  may  take  a  List  as  an  argument,  but 
may  only  use  the  add  and  iterator  methods.)  The  analysis,  a  simple  inter-procedural  dataflow 
analysis,  re-computes  structural  types  for  each  parameter  of  a  method  until  a  fixpoint  is  reached. 
Structural  types  were  not  inferred  for  calls  to  library  methods  (for  modularity  purposes),  nor 
were  they  inferred  for  primitive  types,  common  types  such  as  String  and  Object,  and  cases  where 
the  inferred  structural  type  would  have  a  non-public  member.  Finally,  to  simplify  the  analysis, 
structural  types  were  not  inferred  for  objects  on  the  left-hand  side  of  an  assignment  expression. 

The  analysis  is  conservative;  in  the  case  where  a  parameter  is  not  used  (or  only  methods  of 
class  Object  are  used),  no  structural  type  is  inferred  for  it.  A  parameter  may  be  unused  because 
(a)  it  is  expected  that  overriding  methods  will  use  the  parameter,  or  (b)  because  the  method  may 
make  use  of  the  parameter  when  the  program  evolves,  or  (c)  because  it  is  no  longer  needed,  due 
to  changes  in  the  program.  In  the  case  of  method  overriding,  the  analysis  ensures  that  the  same 
structural  types  are  inferred  for  corresponding  parameters  in  the  entire  method  family. 

The  first  set  of  results  appear  in  Table [4.  i|  In  Ant,  9.7%  of  parameters  were  unused,  47.2%  of 
parameters  had  a  primitive  type,  were  String,  or  were  Object.  For  0.3%  of  parameters,  a  call  was 
made  to  a  non-public  method,  which  means  that  a  structural  type  could  not  be  used  in  this  case 
(as  the  visibility  of  all  members  of  a  structural  interface  must  be  public).  1.0%  of  parameters  could 
not  have  a  structural  type  inferred  due  to  the  fact  that  the  associated  method  was  overriding  a 
method  in  a  library.  Finally,  for  15.8%  of  parameters,  a  structural  type  could  not  be  inferred,  due 
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LOC 

Unused 

Primitive 

type 

Non-public 

call 

Library 

override 

Called 

library 

Assigned 

%  Inferrable 
of  total 

%  Inferrable 
of  candidates 

Ant 

62k 

9.7% 

47.2% 

0.3% 

1.0% 

9.1% 

15.8% 

17.0% 

40.5% 

antlr 

42k 

16.7% 

50.2% 

0.4% 

0.2% 

8.1% 

9.0% 

15.5% 

47.6% 

Apache  coll 

26k 

8.4% 

55.0% 

2.1% 

6.0% 

1.2% 

16.4% 

11.0% 

38.4% 

Areca 

35k 

9.7% 

39.4% 

0.1% 

4.8% 

9.3% 

20.5% 

16.1% 

35.1% 

Cayenne 

95k 

8.3% 

47.0% 

0.5% 

3.1% 

8.1% 

11.2% 

21.9% 

53.2% 

Columba 

70k 

11.6% 

40.8% 

0.6% 

19.8% 

5.5% 

9.0% 

12.6% 

46.4% 

Crystal 

12k 

18.0% 

4.1% 

0.2% 

17.9% 

7.4% 

22.3% 

30.1% 

50.3% 

Drjava 

59k 

13.5% 

42.5% 

0.8% 

13.2% 

7.8% 

7.8% 

14.3% 

47.9% 

Emma 

23k 

20.5% 

42.3% 

0.4% 

0.9% 

7.4% 

8.8% 

19.6% 

54.6% 

freecol 

62k 

8.7% 

38.5% 

0.0% 

11.5% 

3.9% 

11.8% 

25.5% 

61.9% 

hsqldb 

62k 

14.4% 

61.3% 

6.4% 

3.9% 

1.0% 

4.8% 

8.2% 

58.5% 

HttpClient 

18k 

14.3% 

55.7% 

0.1% 

0.3% 

5.7% 

5.1% 

18.8% 

63.5% 

jEdit 

71k 

11.8% 

56.9% 

1.0% 

9.7% 

4.9% 

8.5% 

7.2% 

35.1% 

JFreeChart 

93k 

8.1% 

45.9% 

0.4% 

1.4% 

14.3% 

10.4% 

19.6% 

44.2% 

JHotDraw 

52k 

18.3% 

32.3% 

0.0% 

7.7% 

11.1% 

10.1% 

20.5% 

49.2% 

jruby 

86k 

19.7% 

27.2% 

0.4% 

0.8% 

3.0% 

16.0% 

32.9% 

63.4% 

jung 

26k 

8.1% 

33.8% 

0.1% 

4.8% 

22.9% 

12.0% 

18.2% 

34.3% 

LimeWire 

97k 

13.7% 

45.8% 

1.4% 

7.1% 

7.9% 

6.7% 

17.5% 

54.5% 

log4j 

13k 

12.3% 

46.8% 

0.7% 

4.7% 

6.6% 

10.0% 

18.8% 

53.1% 

Lucene 

24k 

12.3% 

58.3% 

0.6% 

0.1% 

4.9% 

14.8% 

9.2% 

31.8% 

OpenFire 

90k 

14.0% 

39.7% 

0.2% 

6.1% 

7.6% 

10.9% 

21.4% 

53.5% 

pit  collections 

19k 

15.8% 

19.5% 

0.3% 

3.0% 

6.8% 

42.1% 

12.4% 

20.3% 

pmd 

38k 

31.3% 

32.7% 

0.0% 

1.3% 

6.5% 

8.4% 

19.7% 

56.9% 

poi 

50k 

15.9% 

69.8% 

0.7% 

3.3% 

1.3% 

2.1% 

6.7% 

66.2% 

quartz 

22k 

15.4% 

54.2% 

0.0% 

0.8% 

5.9% 

5.6% 

18.2% 

61.2% 

Smack 

40k 

17.2% 

45.3% 

0.2% 

1.6% 

12.5% 

8.1% 

15.1% 

42.2% 

Struts 

28k 

6.3% 

58.1% 

0.1% 

4.4% 

5.1% 

18.9% 

7.1% 

22.8% 

Tomcat 

126k 

13.6% 

54.6% 

0.1% 

3.2% 

3.7% 

11.0% 

13.8% 

48.3% 

xalan 

161k 

10.5% 

56.5% 

1.3% 

2.7% 

2.5% 

10.9% 

15.7% 

54.1% 

Average 

13.7% 

44.9% 

0.7% 

5.0% 

7.0% 

12.0% 

16.7% 

47.9% 

Table  4.1:  Categories  of  method  parameters  when  running  structural  type  inference  over  29 
programs.  “Unused”  denotes  the  percentage  of  parameters  that  were  not  transitively  used  in 
the  program,  “primitive  type”  is  the  percentage  of  parameters  that  were  either  a  primitive  type, 
or  were  String  or  Object,  “non-public  call”  is  the  percentage  of  parameters  on  which  a  non¬ 
public  method  was  called  (in  which  case  a  structural  type  could  not  be  inferred),  and  “library 
override”  is  the  percentage  of  paramters  for  which  a  structural  type  could  not  be  inferred  due  to 
the  fact  that  the  method  was  an  override  of  a  library  method.  “Called  library”  is  the  percentage 
of  parameters  for  which  a  structural  type  could  not  be  inferred  because  a  library  method  was 
transitively  called  and  “assigned”  is  the  percentage  of  parameters  that  were  assigned  to  a  local 
or  member  variable  and  did  not  have  structural  types  computed.  “Percent  inferrable  of  total” 
is  the  percentage  of  all  parameters  that  could  have  a  structural  type  inferred,  while  “percent 
inferrable  of  candidates”  is  the  percentage  of  inferrable  parameters,  when  considering  only 
those  parameters  for  which  a  structural  type  would  be  meaninful. 
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to  the  fact  that  the  parameter  was  assigned  to  a  local  variable  or  member  variable  (this  was  a 
limitation  of  the  analysis). 


Considering  all  parameters,  an  average  of  16.7%  could  have  a  structural  type  inferred.  How¬ 
ever,  if  we  exclude  parameters  that  fall  into  the  categories  in  columns  3-6  (i.e.,  unused  param¬ 
eters,  primitive  types,  non-public  calls,  and  library  overrides),  then  an  average  of  47.9%  of  pa¬ 
rameters  could  have  a  structural  type  inferred.  This  second  figure  is  more  relevant,  as  it  is  not 
meaningful  to  infer  structural  types  for  parameters  that  fall  into  the  aforementioned  categories. 

The  analysis  also  computed  some  characteristics  of  these  structural  types  that  were  inferred; 
results  are  displayed  in  Table  |4.2[  An  average  of  94.0%  of  parameters  were  declared  with  an 
overly  precise  nominal  type  (i.e.,  the  nominal  type  contained  more  methods  than  were  actually 
needed).  For  an  average  of  91.8%  of  the  inferred  parameters  a  corresponding  nominal  type  did 
not  exist  in  the  program  that  would  make  the  parameter  type  z.?,  general  as  possible  (i.e.,  a  nom¬ 
inal  type  that  contained  only  those  methods  transitively  called  on  the  object).  There  were  an 
average  of  3.7  methods  in  the  inferred  structural  types,  across  all  programs,  while  there  were 
an  average  of  41.7  methods  in  the  corresponding  nominal  types.  Finally,  there  was  an  average 
median  of  1.2  structural  types  inferred  for  each  nominal  type  in  the  program,  and  an  average 
maximum  of  23.4  structural  types. 

Note  that  the  data  shows  that  inferred  structural  types  do  not  have  many  methods,^,  while 
the  corresponding  nominal  types  have  quite  a  few  methods.  This  shows  that  there  is  quite  a 
large  degree  of  over  specificity — more  than  a  full  order  of  magnitude — in  addition  to  the  large 
percentage  of  overly  specific  parameters.  This  is  likely  due  to  the  overhead  of  naming  and  defin¬ 
ing  nominal  types,  as  well  as  the  lack  of  retroactive  interface  implementation.  The  analysis  also 
showed  that  when  nominal  types  were  as  general  as  possible,  they  had  very  few  members — one 
or  two  on  average.  This  is  in  accordance  with  previous  work  which  found  that  interfaces  are 
generally  smaller  than  classes  |  Tempero  et  al.  2008) . 


Additional  data.  For  a  given  nominal  type,  there  were  not  many  corresponding  structural 
types  (2.5  on  average,  a  median  of  1.2).  The  data  followed  a  power  law  distribution,  with  an 
average  maximum  of  24;  that  is,  small  values  were  heavily  represented,  but  there  were  also  a 
few  large  values.  The  low  median  suggests  that  the  overhead  of  naming  structural  types  is  not 
necessarily  high;  it  is  plausible  that  programmers  would  be  able  to  name  and  use  structural  types 
for  around  half  of  the  nominal  parameter  types. 

Finally,  if  we  were  to  define  new  interfaces  everywhere  possible,  the  average  increase  in  the 
number  of  interfaces  is  313%,  the  median  is  287%,  and  the  maximum  is  1000%.  This  illustrates 
the  infeasibility  of  defining  new  nominal  types  for  the  inferred  structural  types.  Note  that  only 
those  interfaces  for  which  the  implements  clause  of  a  class  could  be  modified  (i.e.,  those  classes  in 
the  program’s  source)  were  considered;  in  general,  the  situation  is  even  worse,  as  programmers 
may  wish  to  define  new  supertypes  for  types  contained  in  libraries. 


^There  is  one  outlier  in  the  data;  in  pmd,  inferred  structural  types  had  29.5  methods  on  average.  This  is 
due  to  the  use  of  the  visitor  design  pattern— all  visit  methods  are  accessible  from  the  top  visitor  accept  method, 
since  each  override  calls  a  specific  visit  method. 


4.3-  Inferring  Structural  Types  for  Method  Parameters 
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LOG 

%  Inferrable 

%  Overly 
specific 

%  Structural 
needed 

Avg  methods/ 
structural  type 

Avg  methods/ 
nominal  type 

Struct  types/nominal 
median  max 

Ant 

62k 

40.5% 

98.6% 

97.7% 

2.1 

36.0 

1 

27 

antlr 

42k 

47.6% 

100.0% 

98.8% 

2.2 

14.0 

2 

9 

Apache  coll 

26k 

38.4% 

89.5% 

83.0% 

2.0 

16.0 

1 

11 

Areca 

35k 

35.1% 

99.1% 

97.4% 

2.8 

35.9 

1 

35 

Cayenne 

95k 

53.2% 

96.3% 

92.6% 

2.4 

31.3 

2 

27 

Columba 

70k 

46.4% 

99.6% 

98.8% 

1.9 

51.6 

1 

19 

Crystal 

12k 

50.3% 

98.8% 

96.6% 

3.2 

15.7 

1 

19 

Drjava 

59k 

47.9% 

89.5% 

87.1% 

3.2 

56.3 

1 

20 

Emma 

23k 

54.6% 

88.2% 

87.8% 

3.4 

17.1 

1 

9 

freecol 

62k 

61.9% 

98.6% 

97.9% 

2.6 

84.8 

1 

57 

hsqldb 

62k 

58.5% 

99.4% 

99.4% 

1.7 

48.9 

2 

34 

HttpClient 

18k 

63.5% 

96.3% 

94.8% 

3.5 

27.0 

1 

17 

jEdit 

71k 

35.1% 

95.5% 

95.5% 

2.2 

119.6 

1 

20 

JFreeChart 

93k 

44.2% 

97.7% 

93.5% 

3.3 

53.9 

1 

35 

JHotDraw 

52k 

49.2% 

100.0% 

97.2% 

3.0 

57.0 

2 

19 

jruby 

86k 

63.4% 

98.1% 

97.5% 

6.9 

66.1 

1 

85 

jung 

26k 

34.3% 

96.3% 

88.3% 

1.8 

32.1 

1 

15 

LimeWire 

97k 

54.5% 

98.5% 

94.9% 

2.1 

34.6 

1 

21 

log4j 

13k 

53.1% 

96.5% 

95.0% 

2.3 

56.7 

1 

6 

Lucene 

24k 

31.8% 

80.5% 

77.4% 

1.6 

13.5 

1.5 

8 

OpenFire 

90k 

53.5% 

99.4% 

96.7% 

2.4 

37.1 

1 

45 

pit  collections 

19k 

20.3% 

58.2% 

59.3% 

1.5 

39.8 

1 

25 

pmd 

38k 

56.9% 

72.9% 

69.1% 

29.5 

48.2 

2 

23 

poi 

50k 

66.2% 

88.0% 

87.0% 

1.9 

22.8 

1 

8 

quartz 

22k 

61.2% 

100.0% 

99.1% 

2.2 

36.6 

1 

11 

Smack 

40k 

42.2% 

100.0% 

91.6% 

4.4 

29.2 

1 

13 

Struts 

28k 

22.8% 

96.4% 

96.4% 

2.1 

32.4 

1 

13 

Tomcat 

126k 

48.3% 

96.8% 

96.3% 

4.5 

37.6 

2 

32 

xalan 

161k 

54.1% 

96.4% 

96.0% 

5.3 

56.5 

1 

16 

Average 

47.9% 

94.0% 

91.8% 

3.7 

41.7 

1.2 

23.4 

Table  4.2:  Results  of  running  structural  type  inference.  Percent  inferrable  is  the  percentage  of 
candidate  parameters  that  could  have  a  structural  type  inferred  (i.e.,  last  column  in  Fig.  [4^, 
percent  overly  specific  is  the  percentage  of  the  inferrable  parameters  that  have  an  overly  spe¬ 
cific  nominal  type,  percent  structural  needed  is  the  percentage  of  the  inferrable  parameters  for 
which  a  most  general  nominal  type  does  not  exist,  average  methods  per  structural  type  is  the 
average  number  of  methods  in  the  inferred  structural  types,  average  methods  per  nominal  type 
is  the  average  number  of  methods  in  nominal  types  that  appear  as  parameter  types  (includ¬ 
ing  inherited  methods),  and  median/maximum  structural  types  per  nominal  are  the  median 
and  maximum,  respectively,  of  the  number  of  inferred  structural  types  corresponding  to  each 
nominal  type. 


4.3.2  Qualitative  Results 

Though  the  results  show  that  many  parameters  are  overly  specific,  it  is  not  necessarily  a  good 
design  to  make  every  parameter  as  general  as  possible.  This  is  because  a  method  might  be  cur¬ 
rently  only  using  a  particular  set  of  methods,  but  later  code  modifications  may  make  it  necessary 
to  use  a  larger  set;  a  more  general  type  could  hinder  program  evolution.  On  the  other  hand,  more 
general  types  make  methods  more  reusable,  which  aids  program  evolution.  For  this  reason,  a 
refactoring  to  structural  types  (or  even  structural  type  inference)  cannot  be  a  fully  automated 
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process — programmers  must  consider  each  type  carefully,  keeping  in  view  the  kinds  of  program 
modifications  that  are  likely  to  occur.  Additionally,  for  some  structural  types,  there  may  ever  be 
only  one  corresponding  nominal  type,  in  which  case  using  a  structural  type  is  of  limited  utility. 

Accordingly,  an  empirical  question  was  considered:  would  changing  a  given  method  to  have 
the  most  general  structural  types  for  its  parameters  make  the  method  more  general  in  a  way 
that  could  improve  the  program?  To  determine  this,  I  inspected  each  method  and  asked  two 
questions.  First,  does  the  inferred  parameter  type  S  generalize  the  abstract  operation  performed 
by  the  method,  as  determined  by  the  method  name?  Second,  does  it  seem  likely  that  there  would 
be  multiple  subtypes  of  S? 

Two  applications  were  studied:  Apache  Collections  (a  collections  library)  and  Crystal  (a 
static  analysis  framework).  Of  methods  for  which  a  structural  type  was  inferred  on  one  or  more 
parameters,  I  found  that  58%  and  66%,  respectively,  would  be  generalized  in  a  potentially  useful 
manner  if  the  inferred  types  were  used. 

For  example,  in  Apache  Collections,  in  the  class  OnePredicate  (a  predicate  class  that 
returns  true  only  if  one  of  its  enclosing  predicates  returns  true),  the  factory  method 
getinstance (Collection)  had  the  structural  type  { iterator() ;  size() ;  }  inferred  for  its  parame¬ 
ter.  This  would  make  the  method  applicable  to  any  collection  that  supported  only  iteration  and 
retrieving  the  collection  size,  even  if  it  didn’t  support  collection  addition  and  removal  methods. 
There  were  25  other  methods  in  the  library  that  used  this  structural  type.  Another  example  is 
the  method  ListUtils. intersection  which  takes  two  List  objects.  However,  the  first  List  need  only 
have  a  contains  method,  and  the  second  List  need  only  have  an  iterator  method  (for  this  latter 
parameter,  the  interface  Iterable  could  be  used).  There  were  also  8  methods  that  took  an  Iterator 
as  a  parameter,  but  never  called  the  remove  method.  With  a  structural  type  for  the  method,  the 
type  would  clearly  specify  that  a  read-only  iterator  can  be  passed  as  an  argument. 

In  Crystal,  two  methods  took  a  Map  parameter  that  used  only  the  get  and  put  methods. 
Converting  the  method  to  use  this  structural  type  would  make  it  applicable  to  a  map  that  did 
not  support  iteration  (such  a  type  exists  in  Apache  Collections,  for  example).  Also,  there  were 
11  methods  that  use  only  the  methods  getModifiers( )  and  getName( )  on  an  IBinding  object  (an 
interface  in  the  Eclipse  JDT).  Replacing  the  nominal  type  with  a  structural  type  would  allow  the 
program  to  substitute  a  different  “bindings”  class  that  supported  only  those  two  methods. 

Of  course,  for  some  of  these  structural  types,  there  may  not  be  a  large  number  of  classes 
that  implement  its  methods  but  not  all  of  the  methods  of  a  more  specific  nominal  type,  e.g.. 
Collection.  However,  I  believe  that  all  of  the  aforementioned  types  represent  meaningful  abstrac¬ 
tions.  Furthermore,  since  it  is  conceivable  that  a  programmer  may  define  a  class  implementing 
that  abstraction,  using  these  more  general  types  would  increase  the  applications’  reusability. 


Translation  to  White  oak 


Using  the  inference  algorithm,  I  also  developed  an  automated  translation  of  programs  from  Java 
to  Whiteoak  |Gil  and  Maman  2008),  a  research  language  that  extends  Java  with  support  for 
structural  subtyping.  I  performed  this  translation  on  two  programs:  Apache  Collections  and 
Lucene,  confirming  the  correctness  of  the  analysis  and  demonstrating  its  practical  use. 


4.3-  Inferring  Structural  Types  for  Method  Parameters 
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Methods  in  type 

Uses 

Description 

get (Object) ;  cont a insKey (Object) ; 

168 

Read-only  non-iterable  map;  for  instance, 
a  read-only  hashtable® 

itenatorO;  isEmpty();  size(); 

114 

Read-only  iterable  collection  that  knows 
its  size;  for  instance,  a  read-only  list 

add(Object) ;  addAll (Collect ion ) ; 

101 

Write-only  collection;  for  instance,  a  log 

put(Object,  Object); 

55 

Write-only  map 

hasNextO;  next(); 

28 

Read-only  iterator 

contains (Object); 

21 

Read-only  collection  that  does  not  support 
iteration;  for  instance,  a  read-only  hashset 

get(Object);  put(Object,  Object); 

15 

Non-iterable  map;  for  instance,  a  hashtable 

contains(Object);  iterator();  size(); 

11 

Read-only  iterable  collection  that  knows 
its  size  and  can  be  polled  for  the  exis¬ 
tence  of  an  element;  for  instance,  an  iter¬ 
able  hashset 

add(Object);  contains(Object);  iterator();  size(); 

10 

Same  as  above,  but  that  also  supports 
adding  elements 

itenatorO;  size();  toArnay (Object []) ; 

8 

Read-only  collection  that  can  be  converted 
to  an  array;  for  instance,  a  read-only  array 

Table  4.3:  Uses  of  Java  Collections  classes  across  29  programs,  as  inferred  using  the  parameter 
structural  type  inference.  (Erasures  are  used  in  lieu  of  generic  types.) 


4.3.3  Uses  of  Java  Collections  Library 

I  next  considered  inferred  structural  types  that  were  supertypes  of  interfaces  and  classes  in  the 
Java  Collections  Library.  Over  all  applications,  there  were  67  distinct  types  in  total,  though  not 
all  appeared  to  express  an  important  abstraction.  I  made  a  conservative  subjective  finding  that 
at  least  10  of  these  types  were  potentially  useful;  these  are  displayed  in  Table  [4^  along  with  a 
description  of  possible  implementations.  For  instance,  there  were  168  inferred  parameters  that 
used  only  the  get()  and  containsKeyO  methods  of  Map.  It  would  be  useful  to  have  a  type  cor¬ 
responding  to  this  abstraction,  particularly  if  the  map  is  immutable  and  must  have  its  contents 
set  at  creation-time.  A  type  consisting  of  these  two  methods  would  also  be  useful  to  support  the 
pattern  that  once  a  map  is  populated,  clients  should  not  make  modifications. 

The  relatively  high  number  of  occurrences  of  each  of  these  structural  types  suggests  their 
utility,  even  though  the  types  contain  few  methods.  It  further  shows  that  programs  routinely 
make  use  of  types  that  the  library  designers  either  did  not  anticipate  or  chose  not  to  support. 

In  summary,  the  data  shows  that  programs  make  repeated  use  of  many  implicit  structural 
types.  A  language  that  would  allow  defining  these  types  explicitly  could  be  beneficial,  as  it  can 
help  programmers  make  their  methods  more  generally  applicable. 


4.3.4  Related  work 

Forster  [Forster  2006]  and  Steimann  jSteimann  2007)  have  described  experience  using  the 
Infer  Type  refactoring,  which  generates  new  interfaces  for  inferred  types  and  replaces  uses  of 
overly  specific  types  with  these  interfaces.  This  analysis  is  more  general  than  the  one  used 
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here,  because  it  considers  all  type  references,  not  just  parameter  types.  However,  the  refac¬ 
toring  is  limited  by  the  fact  that  classes  in  libraries  cannot  retroactively  implement  new  inter¬ 
faces.  Steimann  found  that  when  applying  this  refactoring,  the  number  of  total  interfaces  almost 
quadrupled — an  increase  of  369%.^  In  his  analysis,  there  were  an  average  of  2.8  and  4.5  refer¬ 
ence  per  inferred  type,  respectively,  in  the  two  studied  applications,  DrawSWF  and  JHotDraw. 
By  comparison,  in  DrawSWF,  I  found  that  structural  types  were  used  in  an  average  of  2.7  param¬ 
eters;  for  JHotDraw  this  value  was  3.3,  which  differs  from  Steimann’s  result.  This  discrepancy  is 
likely  due  to  the  fact  that  he  considered  types  other  than  those  of  parameters.  Additionally,  both 
Forster  and  Steimann  found  that  the  number  of  variables  typed  with  each  new  inferred  interface 
followed  a  power  law  distribution,  which  is  what  I  also  found  for  parameters. 

Summary  of  results 

In  summary,  the  parameter  analysis  suggests  that  there  are  many  nominal  types  that  could  be 
made  more  general  using  structural  subtyping,  and  most  of  these  were  qualitatively  determined 
to  be  useful.  Also,  the  inferred  structural  types  had  an  order  of  magnitude  fewer  methods  than 
the  corresponding  nominal  types.  It  is  infeasible  to  define  new  nominal  types  to  correct  this, 
due  to  the  number  of  structural  types  inferred  per  nominal  type  and  the  resulting  percentage 
increase  in  interfaces. 


4.4  Throwing  “Unsupported  Operation”  Exceptions 

In  the  Java  Collections  Library,  there  are  a  number  of  “optional”  methods  whose  documentation 
permits  them  to  always  throw  an  exception.  This  decision  was  due  to  the  practical  consideration 
of  avoiding  an  “explosion”  of  interfaces;  the  library  designers  mentioned  that  at  least  25  new 
interfaces  would  be  otherwise  required  |Sun  Microsystems||2003|. 

To  determine  if  such  super-interfaces  would  be  useful  in  practice,  the  methods  in  the  sub¬ 
ject  programs  that  unconditionally  throw  an  UnsupportedOperationException  were  totalled.  The 
program  that  had  the  most  such  methods  was  Apache  Collections:  there  were  148  methods  that 
unconditionally  throw  the  exception  (out  of  3669  total  methods,  corresponding  to  4%).  Next, 
those  methods  that  were  overriding  a  method  in  the  Java  Collections  Library  were  considered. 
To  encode  these  optional  methods  directly  would  require  18  additional  interfaces.  There  are 
only  27  interfaces  defined  in  the  library,  so  this  represents  a  67%  increase.  Note  that  this  is  a 
conservative  estimate,  as  interactions  between  classes  (e.g.,  an  Iterable  returning  a  read-only 
Iterator)  were  not  considered.  A  selection  of  these  structural  super-interfaces  is  summarized  in 
Table I4.4I  For  instance,  there  were  50  iterator  classes  that  did  not  support  the  remove ()  opera¬ 
tion,  and  19  subclasses  of  Collection  that  supported  a  read-only  interface. 

Note  that,  with  the  exception  of  the  read-only  iterator,  the  sets  of  interfaces  in  Tablesjq^and 

different  applications  use  different  subsets  of  the  methods  of  a  class. 

^This  differs  slightly  from  our  average  of  313%,  though  this  difference  is  likely  due  to  the  fact  that  Steimann 
considered  only  two  applications. 
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are  distinct  from  one  another  (though  some  are  subtypes).  This  is  likely  due  to  the  fact  that 
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Number  of  classes 


Read-only  Iterator  50 

Read-only  Collection  19 

Read-only  Map  9 

Read-only  Map.  Entry  6 

Read-only  Listiterator  6 

Collection  supporting  everything  but  removal  5 

Map  supporting  everything  but  removal  4 

Collection  supporting  only  read  and  removal  methods  1 

Collection  supporting  iteration,  addition,  and  size  only  1 

Listiterator  supporting  read,  add,  and  remove  (but  not  set( ))  1 

Listiterator  supporting  only  read  and  set  ( )  operation  1 

Map  supporting  read,  put,  and  size  only  1 

Map  supporting  read  and  put,  but  not  size  or  removal  1 

Map  supporting  everything  but  entrySet(),  values()  and  containsValue( )  1 


Table  4.4:  A  selection  of  the  structural  interfaces  “implemented”  by  classes  in  the  subject 
programs  once  methods  unconditionally  throwing  an  UnsupportedOperationException  are  re¬ 
moved.  (Actual  method  sets  are  omitted  to  conserve  space.) 

Structural  subtyping  could  be  helpful  for  statically  ensuring  that  “unsupported  operation” 
exceptions  cannot  occur,  as  it  would  allow  programmers  to  express  these  super-interfaces  di¬ 
rectly. 


4.5  Common  Methods 


In  my  experience,  there  are  situations  where  two  types  share  an  implicit  common  supertype,  but 
this  relationship  is  not  encoded  in  the  type  hierarchy.  For  example,  suppose  two  classes  both 
have  a  getName  method  with  the  same  signature,  but  there  does  not  exist  a  supertype  of  both 
classes  containing  this  method.  I  call  getName,  and  methods  like  it,  common  methods.  Common 
methods  can  occur  when  programmers  do  not  anticipate  the  utility  of  a  shared  supertype  or 
when  two  methods  have  the  same  name,  but  perform  different  operations;  e.g.,  Cowboy.draw( ) 
and  Circle. draw()  |Magnusson|i99i |. 

Accordingly,  this  section  aims  to  answer  three  questions:  (1)  how  often  do  common  methods 
occur,  (2)  how  many  common  methods  represent  an  accidental  name  clash,  and  (3)  do  common 
methods  result  in  code  clones? 


4.5.1  Frequency 

A  simple  whole-program  analysis  to  count  the  number  of  common  methods  in  each  application 
was  performed.  Only  public  instance  methods  were  considered  (resulting  in  slightly  different 
data  than  that  previously  presented  [Malayeri  and  Aldrich|200^).  Results  are  in  Table 
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Overall,  common  methods  comprise  an  average  of  19%  of  all  public  instance  methods.  That  is, 
for  19%  of  methods,  there  existed  another  method  with  the  same  name  and  signature  and  the 
method  was  not  contained  in  a  common  supertype  of  the  enclosing  types. 
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LOC 

Number  of 
types 

Types  with  >  1 
common  method 

Percentage 

%  common 
methods 

Avg  #  classes/ 
common  signature 

Ant 

62k 

945 

65 

6.9% 

31.3% 

3.7 

antlr 

42k 

226 

26 

11.5% 

23.6% 

2.7 

Apache  Collections 

26k 

550 

19 

3.5% 

7.3% 

2.7 

Areca 

35k 

362 

30 

8.3% 

15.4% 

2.7 

Cayenne 

95k 

1415 

104 

7.3% 

18.1% 

2.8 

Columba 

70k 

1232 

48 

3.9% 

17.3% 

3.1 

Crystal 

12k 

211 

4 

1.9% 

5.1% 

2.9 

Drjava 

59k 

927 

65 

7.0% 

12.1% 

2.6 

Emma 

23k 

443 

22 

5.0% 

18.7% 

3.4 

freecol 

62k 

569 

55 

9.7% 

20.6% 

2.7 

hsqldb 

62k 

355 

31 

8.7% 

19.5% 

2.6 

HttpClient 

18k 

231 

19 

8.2% 

15.0% 

2.6 

jEdit 

71k 

880 

40 

4.5% 

11.7% 

2.5 

JFreeChart 

93k 

789 

301 

38.1% 

39.5% 

3.9 

JHotDraw 

52k 

616 

59 

9.6% 

19.0% 

2.8 

jruby 

86k 

997 

83 

8.3% 

15.6% 

3.1 

jung 

26k 

531 

24 

4.5% 

19.3% 

2.4 

LimeWire 

97k 

1689 

88 

5.2% 

17.7% 

3.1 

log4j 

13k 

201 

4 

2.0% 

13.6% 

2.4 

Lucene 

24k 

398 

21 

5.3% 

13.4% 

2.6 

OpenFire 

90k 

1039 

110 

10.6% 

19.0% 

3.0 

pit  collections 

19k 

812 

60 

7.4% 

7.5% 

2.8 

pmd 

38k 

478 

24 

5.0% 

12.0% 

2.7 

poi 

50k 

539 

62 

11.5% 

20.9% 

2.6 

quartz 

22k 

158 

24 

15.2% 

20.0% 

2.4 

Smack 

40k 

847 

115 

13.6% 

23.5% 

3.3 

Struts 

28k 

609 

158 

25.9% 

45.2% 

2.7 

Tomcat 

126k 

1727 

234 

13.5% 

32.6% 

3.6 

xalan 

161k 

1223 

94 

7.7% 

16.1% 

2.9 

Average 

9.3% 

19.0% 

2.9 

Table  4.5:  Common  methods  for  each  application.  Number  of  types  indicates  the  total  number 
of  types  in  the  application,  types  with  greater  than  one  common  method  is  the  number  of  types 
that  share  more  than  one  common  method,  percentage  is  the  percentage  of  this  compared 
to  the  total  number  of  types,  percent  common  methods  is  the  percentage  of  public  instance 
methods  that  is  a  common  method,  and  average  number  of  classes  per  common  signature  is  the 
average  number  of  classes  for  each  common  method  signature. 


The  number  of  types  that  share  at  least  two  common  methods  with  another  type  was  also 
computed;  there  were  an  average  of  9%  of  such  types.  These  are  the  cases  in  which  a  structural 
supertype  is  most  likely  to  be  useful.  This  high  percentage  indicates  that  there  are  a  number  of 
implicit  structural  types  in  most  applications. 

For  example,  in  Apache  Collections,  UnmodifiableSortedMap  and  OrderedMap  share  the 
methods  firstKeyO  and  lastKey().  And,  AbstractLinkedList  and  SequencedHashMap  share  the 
methods  getFirst()  and  getLast().  Finally,  BoundedMap  and  BoundedCollection  have  the  com¬ 
mon  methods  isFull()  and  maxSize(). 

In  Lucene,  a  document  indexing  and  search  library,  RAMOutputStream  and  RAMInputStream 
both  support  the  seek( ),  close( ),  and  getFilePointer( )  methods,  which  might  be  useful  to  move 
to  a  supertype.  Also,  the  classes  PhraseQuery  and  MultiPhraseQuery  both  support  the  methods 
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add(Term),  getPositions(),  getSlop(),  and setSlop(int). 

4.5.2  Accidental  Name  Clashes 

Of  course,  to  interpret  this  data,  we  must  consider  cases  where  the  common  methods  have  the 
same  meaning,  and  where  callers  are  likely  to  call  the  methods  with  the  same  purpose  in  mind.  If 
two  methods  have  the  same  meaning,  it  might  be  useful  to  define  a  structural  type  consisting  of 
that  method.  Two  methods  are  defined  as  “having  the  same  meaning”  if  they  perform  the  same 
abstract  operation,  taking  into  account  (a)  the  semantics  of  the  method,  and  (b)  the  semantics  of 
the  enclosing  types.  This  determination  was  made  by  examining  the  source  code,  using  javadoc 
where  available. 

Two  applications  were  studied:  Apache  Collections  and  Lucene.  In  Collections,  under  con¬ 
dition  (a),  there  were  no  methods  that  had  the  same  signature  but  performed  different  abstract 
operations.  However,  there  were  2  cases  (1%  of  all  common  methods)  where  the  methods  had  the 
same  meaning,  but  the  enclosing  classes  did  not  appear  to  be  semantic  subtypes  of  some  com¬ 
mon  supertype  containing  that  method;  i.e.,  condition  (b)  was  not  satisfied.  For  example,  the 
classes  ChainedClosure  and  SwitchClosure  both  had  a  getClosures()  method,  but  ChainedClosure 
calls  each  of  these  closures  in  turn,  while  SwitchClosure  calls  that  closure  whose  predicate  returns 
true. 

In  Lucene,  there  were  42  instances  of  methods  that  had  the  same  signature,  but  did  not 
have  the  same  meaning  (19%  of  all  common  methods).  In  32  of  these  cases,  the  methods  were 
actually  performing  a  different  abstract  operation.  For  example,  FlitIterator.length( )  returned 
the  number  of  hits  for  a  particular  query,  while  Payload. length ()  returned  the  length  of  the 
payload  data.  An  additional  10  cases  did  not  satisfy  condition  (b)  above.  For  example,  in  a  high- 
level  class  IndexModifier,  there  were  several  cases  where  a  method  m  performed  some  operation, 
then  called  IndexWriter.m,  the  latter  performing  a  lower-level  operation.  So,  the  semantics  of 
the  methods  were  similar,  but  the  semantics  of  each  class  was  different. 

Overall,  the  data  is  promising,  as  it  indicates  that  most  common  methods  have  the  same 
meaning  and  would  benefit  from  being  contained  in  a  structural  supertype — 90%  on  average, 
across  both  applications.  Structural  sub  typing  would  allow  these  methods  to  be  called  in  a 
generic  manner,  without  the  need  to  create  additional  interfaces. 


4.5.3  Code  Clones 


I  hypothesized  that  common  methods  can  lead  to  code  clones,  as  there  is  a  common  structure 
that  is  not  expressed  in  the  type  system.  To  determine  this,  two  applications  were  examined: 
Eclipse  JDT  and  Azureus. 

In  the  Eclipse  Java  Development  Tools  (JDT),  the  classes  FleldAccess  and  SuperFleldAccess 
have  no  superclass  other  than  Expression.  The  same  problem  occurs  with  Method  Invocation  and 
SuperMethodInvocatlon,  and  Constructorinvocatlon  and  SuperConstructorInvocatlon.  I  found  44 
code  clones  involving  these  types  (though  some  were  only  a  few  lines  long) .  An  example  of  a  code 
clone  involving  Methodinvocatlon  and  SuperMethodInvocatlon  appears  in  Eig.  4.1  Another  code 


clone  involving  SuperConstructorInvocatlon  and  Constructorinvocatlon  appears  in  Eig. [4. 2 
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private  InlineMethodRefactoring(ICompilationUnit  unitj 
Methodinvocation  node,  int  offset,  int  length) 

{ 

this(unit,  (ASTNode)node,  offset,  length); 
fTargetProvider=  TargetProvider.create(unit,  node); 
fInitialMode=  fCurrentMode=  Mode . INLINE_SINGLE; 
fDeleteSource=  false; 

1 

private  InlineMethodRefactoring(ICompilationUnit  unit, 
SuperMethodInvocation  node,  int  offset,  int  length) 

{ 

//same  method  body  as  above 

} 


Figure  4.1:  Example  of  code  duplication  in  the  Eclipse  JDT.  Structural  subtyping  could  elimi¬ 
nate  this  duplication. 


Similarly,  in  the  Eclipse  SWT  (Simple  Windowing  Toolkit),  there  are  13  classes  (such  as 
Button,  Label,  and  Link)  with  the  methods  getText  and  setText  that  get  and  set  the  main  text  for  the 
control.  But,  there  is  no  common  IText  interface.  Azureus,  a  BitTorrent  client,  is  an  application 
that  requires  the  ability  to  call  these  methods  in  a  generic  fashion.  Azureus  is  localized  for  a 
number  of  languages,  which  can  be  changed  at  runtime.  Accordingly,  there  are  several  instances 
of  code  similar  to  that  of  Fig.  [4^ 

Note  that  some  of  this  code  duplication  might  be  avoided  if  the  class  hierarchy  were  refac¬ 
tored.  Obviously,  this  is  not  always  possible — e.g.,  Azureus  cannot  modify  SWT. 

The  code  duplication  in  these  examples  can  be  dramatically  reduced  by  taking  advantage  of 
structural  type.  For  example,  Fig.|4.4|shows  how  the  code  block  of  Fig.  [4^  could  be  re-written 
with  Unity  structural  types. 

In  summary,  common  methods  can  lead  to  undesirable  code  duplication.  Structural  subtyp¬ 
ing  can  help  eliminate  this  problem,  without  refactoring  the  class  hierarchy. 


4.6  Cascading  instanceof  Tests 


I  considered  the  question  of  whether  structural  subtyping  could  provide  benefits  if  used  in  con¬ 
junction  with  other  language  features — external  methods  in  particular. 

Since  Java  does  not  support  any  form  of  external  dispatch,  programmers  often  compensate 
by  using  cascading  instanceof  tests  in  client  code.  This  programming  pattern  is  problematic 
because  it  is  tedious,  error-prone,  and  lacks  extensibility  [Clifton  et  al.||2006|.  Many  instances 
of  this  pattern  could  be  re-written  to  use  external  methods,  but  a  problem  arises  if  an  instanceof 
test  is  performed  on  an  expression  of  type  Object. 
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case  ASTNode.SUPER_CONSTRUCTOR_INVOCATION:  { 

SuperConstructorInvocation  superInvocation=  (SuperConstructorInvocatlon)  parent; 
IMethodBinding  superBindlng=  superinvocation . resolveConstructorBlnding( ) ; 
if  (superBinding  !=  null)  { 

return  getParameterTypeBinding(nodej  superinvocation . arguments() j  superBinding); 

5 

break; 

1 

case  ASTNode.CONSTRUCTOR_INVOCATION:  { 

Constructorinvocation  constrInvocation=  (Constructorinvocation)  parent; 
IMethodBinding  constrBinding=  constr Invocation . resolveConstructorBinding( ); 
if  (constrBinding  !=  null)  { 

return  getParameterTypeBinding(nodej  constrinvocation . arguments() j  constrBinding); 

] 

break; 


Figure  4.2:  Code  duplication  involving  SuperConstructorInvocation  and  Constructorinvocation. 
Only  the  highlighted  lines  of  code  differ  in  the  two  blocks. 


To  illustrate  this,  let  us  consider  how  instanceof  tests  would  be  translated  to  external  meth¬ 
ods.  Suppose  we  have  a  cascaded  instanceof,  with  each  case  of  the  form  “[else]  if  expr  instanceof 
Ci  {  blocki  This  would  be  translated  to  an  external  method  /  defined  on  expr’s  class,  and 
overridden  for  each  C,-  by  defining  C/./  {  blocki  I-  The  top  part  of  Fig.  4.5  3  shows  the  exter¬ 
nal  methods  translated  from  the  instanceof  tests  in  Fig.  4.51  (but  without  an  external  method 
defined  on  Object,  the  type  of  query,  which  I  will  come  to  in  a  moment). 


A  problem  arises  when  the  target  expression  in  the  instanceof  test  is  of  type  Object,  as  an  ex¬ 
ternal  method  must  be  defined  on  Object,  then  overridden  for  each  type  tested  via  an  instanceof. 
The  problem  with  this  solution  is  that  it  pollutes  the  interface  of  Object.  In  many  cases,  the 
implementation  of  this  method  performs  a  generic  fallback  operation  that  does  not  make  sense 
for  an  object  of  arbitrary  type — but  this  method  becomes  part  of  every  class’s  interface  and  im¬ 
plementation.  (While  it  is  also  possible  to  pollute  the  interface  of  an  arbitrary  class  C,  this  is 
generally  less  severe,  and  detecting  such  a  situation  requires  application-specific  knowledge.) 


To  determine  the  prevalence  of  this  pattern,  instanceof  tests  in  8  applications  were  manu¬ 
ally  examined.  The  result  of  this  analysis  was  that  13%  to  54%  (with  an  average  of  26%)  were 
performing  a  cascading  instanceof  test  on  an  expression  of  type  Object  (see  Table|4.6|. 

Structural  subtyping  provides  one  solution  to  this  problem.  The  type  of  the  expression  on 
which  the  instanceof  is  performed  would  be  changed  from  Object  to  the  structural  type  con¬ 
sisting  of  the  newly  defined  external  method  /.  That  is,  instead  of  making  the  target  operation 
applicable  to  an  arbitrary  object,  it  would  be  applicable  to  only  those  objects  that  contain  method 
/.  Figure [4^  defines  an  external  method  toOuery  on  String  and  Ouery,  then  uses  the  structural 
type  { toOuery  (...)}  as  the  type  for  the  List  elements.  The  advantage  of  using  structural  subtyping 
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if  (widget  instanceof  Label) 

if  (widget  instanceof  CoolBar)  { 

((Label)  widget).  setText(message) ; 

CoolItem[]  items  =  ((CoolBar)widget) .getltems(); 

else  if  (widget  instanceof  CLabel) 

for(int  i  =  0;  i  <  items . length;  i++)  { 

((CLabel)  widget).  setText(message) ; 

Control  control  =  items[i] . getControl( ) ; 

else  if  (widget  instanceof  Group) 

update La nguageForCont rol ( cont rol ) ; 

((Group)  widget).  setText(message); 

1 

...  //  5  more  items 

}  else  if  (widget  instanceof  TabFolder)  { 

// same  code  as  highlighted  above 
}  else  if  (widget  instanceof  CTabFolder)  { 

// same  code  as  highlighted  above 
...  //  5  more  items 

(a)  (b) 

Figure  4.3:  Code  excerpts  from  Azureus,  illustrating  an  awkward  coding  style  and  duplication. 


let 

widget:  Widget(setText:  ( )  =►  string  ^  unit)  =  .  .  . 
in 

widget. setText  message 


Figure  4.4:  Code  block  of  Fig.  4.3 1  re-written  in  Unity. 


is  that  the  main  code  can  call  this  method  uniformly.® 

Thus,  for  many  applications,  there  is  a  potential  benefit  to  using  structural  subtyping  in  a 
language  that  supports  external  dispatch;  an  average  of  26%  of  instanceof  tests  could  be  elimi¬ 
nated. 

Note  that  since  we  refined  the  element  type  of  the  List  object,  this  obviates  the  need  for  the 
error  condition — an  additional  advantage.  However,  it  is  not  always  possible  to  refine  types  to  a 
structural  type;  an  expression  may  simply  have  type  Object,  due  to  the  loss  of  type  information. 
In  such  a  case,  it  would  be  possible  to  re-write  the  code  using  a  structural  downcast.  Though  the 
use  of  casts  would  not  be  eliminated,  there  are  still  several  advantages  to  this  implementation 
style.  First,  the  external  methods  could  be  changed  without  having  to  also  modify  the  method 
that  uses  them.  Also,  if  subclasses  are  added,  a  new  internal  or  external  method  could  be  defined 
for  them.  Finally,  since  the  proposed  cast  would  use  a  structural  type,  it  would  be  more  general, 
applying  to  any  type  for  which  the  method  were  defined. 


®Note  that  it  would  not  be  possible  to  make  use  of  a  nominal  interface  containing  the  method  /  to  call  the 
method  in  a  generic  manner.  Recall  that  for  external  methods  to  be  modular,  once  a  method  is  defined  as  an 
internal  method,  it  cannot  be  implemented  with  an  external  method;  see  Sect. 
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Original  Java  Code 


List  qlist  =  ... 

Object  query  =  qlist. get(i)j 

Query  q  =  null; 

if  (query  instanceof  String) 

q  =  parser. parse((String)  query); 
else  if  (query  instanceof  Query) 
q  =  (Query)  query; 
else 

System. err. println("Unsupported  query  type"); 


Unity  Re-Write 


method  string. toQuery:  ( )  =>  QueryParser  ^  Query  = 
fun  parser:  QueryParser  ->  parser. parse  this 
method  Query. toQuery:  ( )  =>  QueryParser  Query  = 
fun_->  this 


using  toQuery  in 

type  QueryConvert  =  Object  (toQuery:  ( )  =>  QueryParser  ^  Query) 

List<QueryConvert>  qlist  =  . . . 

let  q  :  Query  =  qlist.get(i). toQuery  (parser) 


Figure  4.5:  Rewriting  instanceof  using  structural  subtyping  and  external  dispatch.  At  the  top  is 
the  original  code;  below  is  the  translated  code,  which  defines  the  structural  type  QueryConvert 
and  external  methods  on  Query  and  String.  Note  that  the  translated  code  eliminates  the  need 
for  the  error  condition. 


4.7  Java  Reflection  Analysis 

1  aimed  to  answer  the  following  question:  do  Java  programs  use  reflection  where  structural  types 
would  be  more  appropriate?  Uses  of  reflection  likely  fall  into  two  categories:  cases  where  dy¬ 
namic  class  instantiation  and  classloading  are  used,  and  cases  where  the  type  system  is  not  suf¬ 
ficiently  powerful  to  express  the  programming  pattern  used.  It  is  difficult  to  eliminate  reflection 
in  the  first  category,  as  these  uses  represent  an  inherently  dynamic  operation.  However,  some 
of  the  uses  in  the  second  category  could  potentially  be  rewritten  using  structural  downcasts. 
Reducing  the  uses  of  reflection  is  beneficial  as  it  decreases  the  number  of  runtime  errors  and 
can  improve  performance. 

Across  the  29  subject  programs,  an  average  of  32%  of  uses  of  the  reflection  method 
Class. getMethod  could  be  re-written  using  a  structural  downcast  (see  Table  A  structural 
downcast  is  preferable  to  reflection  because  type  information  is  retained  when  later  calling 
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instanceof 

Expression  of  type  Object 

Percentage 

Apache  collections 

225 

75 

33% 

Areca 

77 

10 

13% 

JHotDraw 

229 

50 

22% 

log4j 

54 

8 

15% 

Lucene 

56 

10 

18% 

PLT  collections 

119 

64 

54% 

Smack 

56 

20 

36% 

Tomcat 

959 

158 

16% 

Average 

26% 

Table  4.6:  Total  instanceof  tests,  the  number  present  in  cascading  if  statements  that  perform 
the  test  on  an  expression  of  type  Object,  and  that  number  expressed  as  a  percentage.  Code 
written  using  this  pattern  can  be  translated  to  a  language  with  structural  subtyping  and  external 
dispatch. 


methods,  as  opposed  to  Method. invoke,  which  is  passed  an  Object  array  and  must  typecheck 
the  arguments  at  runtime.  Additionally,  it  is  easier  to  combine  sets  of  methods  in  a  downcast; 
when  using  reflection,  each  method  must  be  selected  individually.  There  is  also  the  potential  to 
make  method  calls  more  efficient,  which  is  difficult  with  reflection,  due  to  the  low-level  nature  of 
the  available  operations.  (For  example,  the  language  Whiteoak  |Gil  and  Maman  20o8|  supports 
efficient  structural  downcasts.) 

In  summary,  the  high  percentage  of  reflection  uses  that  can  be  translated  to  structural  down¬ 
casts  suggests  that  programmers  may  sometimes  use  reflection  as  a  workaround  for  lack  of  struc¬ 
tural  types. 


4.8  Summary  and  Conclusions 


In  summary,  I  found  that  a  number  of  different  aspects  of  Java  programs  suggest  the  potential 
utility  of  structural  subtyping.  While  some  of  the  results  are  not  as  strong  as  others,  taken  to¬ 
gether  the  data  suggests  that  programs  could  benefit  from  the  addition  of  structural  subtyping, 
even  if  they  were  written  in  a  nominally-typed  language.  In  particular,  structural  subtyping  has 
the  potential  be  used  to  improve  the  reusability  and  maintainability  of  existing  object-oriented 
programs. 

This  chapter  provided  evidence  to  support  hypothesis  In  particular,  I  presented  evi¬ 
dence  suggesting  that  structural  subtyping  could  help  make  method  parameters  more  general 
(Sect.  4.3 1.  There  was  a  high  frequency  of  common  methods  (Sect|4.5.i|,  and  a  low  frequency  of 
common  methods  representing  an  accidental  name  clash  (Sect  4.5.2I.  Finally,  we  saw  evidence 
that  some  cases  of  code  duplication  could  be  avoided  with  structural  subtyping  (Sect.  4.5. 3|. 

Additionally,  I  showed  that  existing  language  designs  can  lead  to  coding  patterns  that  defer 
errors  to  runtime,  coding  patterns  that  could  be  re-written  with  structural  subtyping  to  pro¬ 
vide  more  static  typechecking  in  these  situations.  In  particular,  some  Java  runtime  exceptions 
(i.e.,  OperationUnsupportedException)  can  be  eliminated  in  a  straightforward  manner  with  a  de- 
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Uses  of  getMethod  ( ) 

Could  be  rewritten 

Percentage 

Ant 

36 

9 

25% 

Apache  Collections 

4 

3 

75% 

Areca 

1 

0 

0% 

Azureus 

27 

6 

22% 

Cayenne 

28 

4 

14% 

columba 

10 

8 

80% 

Drjava 

7 

2 

29% 

emma 

2 

1 

50% 

freecol 

1 

1 

100% 

hsqldb 

2 

0 

0% 

HttpClient 

8 

6 

75% 

jedit 

10 

7 

70% 

jfreechart 

1 

1 

100% 

JHotDraw 

26 

1 

4% 

jruby 

17 

6 

35% 

jung 

1 

1 

100% 

log4j 

4 

1 

25% 

openfire 

2 

0 

0% 

pmd 

2 

2 

100% 

quartz 

3 

2 

67% 

struts 

2 

0 

0% 

tomcat 

37 

10 

27% 

xalan 

28 

11 

39% 

Totals 

259 

82 

32% 

Table  4.7:  Uses  of  the  reflection  method  Class. getMethod,  and  the  number  and  percentage 
that  could  be  re-written  using  a  structural  downcast.  Programs  that  did  not  call  this  method 
are  omitted.  The  percentage  entry  in  the  last  row  is  calculated  by  dividing  the  total  “could  be 
rewritten”  by  the  total  “uses  of  getMethod” 


sign  that  uses  structural  subtyping  (Sect.  [4^.  Additionally,  some  uses  of  Java  reflection  can  be 
converted  to  uses  of  structural  subtyping  (Sect.  4.7 1.  Together,  this  data  supports  hypothesis [In| 

Finally,  the  study  in  Sect.  4.6  showed  the  synergy  between  structural  subtyping  and  external 
dispatch:  hypothesis  [Tvl  The  data  showed  that  many  cases  of  cascading  instanceof  tests  in  Java 
programs  can  improved  if  re-written  using  a  combination  of  structural  subtyping  and  external 
methods,  a  re-writing  which  allows  an  existing  class  to  be  adapted  to  a  new  context. 

I  hope  that  the  results  of  this  study  will  be  used  to  inform  designers  of  future  programming 
languages,  as  well  as  serve  as  a  starting  point  for  further  empirical  studies  in  this  area.  Ultimately, 
one  must  study  the  way  structural  subtyping  is  eventually  used  by  mainstream  programmers; 
this  work  serves  as  a  step  in  that  direction. 
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Chapter  5 

Additional  Related  Work 


I  have  discussed  the  most  closely  related  work  in  each  appropriate  chapter  (see  Sections 


2.4.2 


3.3 


2.6 


3.8  and|4.3|l.  In  this  chapter,  I  provide  further  detail  and  describe  additional  related 


work  on  the  topics  of  structural  subtyping,  retroactive  abstraction,  external/multimethod  dis¬ 
patch,  multiple  inheritance,  and  related  empirical  studies. 


5.1  Structural  Subtyping 


In  Sect.  2.6  I  showed  that  although  languages  with  only  nominal  subtyping  (such  as  Java)  can 


be  extended  to  provide  support  for  multiple  dispatch,  these  languages  do  not  have  the  flexibility 
of  languages  with  structural  subtyping.  In  particular,  such  languages  require  programmers  to 
declare  (in  advance)  all  the  types  they  wish  to  use  as  abstractions,  regardless  of  whether  those 
types  are  required  for  dispatch. 


Intersection  types  are  useful  for  expressing  combinations  of  types  jCoppo  and  Dezani- 

lCiancaglini||i978{  Coppo  et  al. 

1979  Pottinger 

1980 

Biichi  and  Week 

1998  ,  but  they  do  not 

solve  the  problem  of  adding  retroactive  supertypes.  Mixins  and  traits  are  designed  mainly  for 


code  reuse  |Bracha  and  Cook|  i99o||Ancona  and  Zucca 

1996 

Ducasse  et  al.| 

20o6j  Fisher  and 

Reppy 

20041,  and  therefore  do  not  properly  address  the 

issues  of  retroactive  abstraction  and 

multimethods.  I  will  revisit  the  topic  of  both  mixins  and  traits  in  the  context  of  the  multiple 
inheritance  features  of  Unity. 

As  previously  mentioned,  structural  subtyping  has  been  extensively  studied  in  both  formal 
and  applied  settings  |Cardelli|i988|||Bruce  et  al.[2003{  Fisher  and  Reppyjiggg  Leroy  et  al.||2004|, 
but  these  formalisms  and  languages  provide  only  internal  dispatch.  One  of  these  languages, 
Moby,  has  particular  similarities  to  Unity,  as  it  both  supports  structural  subtyping  and  a  form  of 
tag  subtyping  through  its  inheritance-based  subtyping  mechanism,  this  latter  mechanism  bear¬ 
ing  similarity  to  sub-branding  in  Unity  [Fisher  and  Reppy|i999  2002) .  This  allows  expressing 


many  useful  subtyping  constraints,  but  Moby’s  class  types  are  not  integrated  with  object  types 
in  the  same  way  as  in  Unity.  For  instance,  in  Moby,  it  is  not  possible  to  express  the  constraint 
that  an  object  should  have  a  particular  class  and  should  have  some  particular  methods  (that  are 
not  defined  in  the  class  itself).  Additionally,  the  object-oriented  core  of  Moby  supports  only 
internal  dispatch.  Moby  does  also  include  “tagtypes”  that  are  very  similar  to  brands  in  Unity. 
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These  can  be  used  to  support  downcasts  or  to  encode  multimethods,  but  they  are  disjoint  from 
the  object-oriented  core  of  the  system. 


A  more  recent  language  design  for  structural  subtyping  is  provided  in  Scala  |  Odersky  and 


Zenger[2005  Odersky|2007|,  through  type  refinements.  Since  Scala  also  includes  nominal  types, 


intersection  types  allow  combining  the  two  components.  However,  Scala  does  not  include  gen¬ 
eral  external  dispatch,  does  not  allow  structural  constraints  to  be  placed  on  the  receiver,  and  does 
not  permit  the  definition  of  structural  recursive  types.  Additionally,  these  aspects  of  Scala’s  type 
system  have  not  yet  been  formalized  (nor  proved  sound). 

There  has  been  a  line  of  work  that  considers  the  question  of  how  to  add  structural  types  to 
existing  languages,  such  as  C++  and  Java  |  Baumgartner  and  Russo  1997  Laufer  et  al.|20oo{  Gil 


and  Maman||20o8 1 .  The  aforementioned  work  differs  from  Unity,  however,  in  that  it  primarily 


focuses  on  implementation  and  integration  issues. 

As  previously  mentioned  (Sect.  2.6 1,  Cecil  contains  “where”  clauses  that  can  model  some 
aspects  of  structural  types,  but  they  can  only  appear  on  top-level  methods  and  can  require  ver¬ 
bose  parameterization,  in  contrast  to  languages  with  true  structural  subtyping.  Cecil  has  the 
most  sophisticated  form  of  “where”  clause  |Litvinov[i9^ 


2003 


Chambers  and  the  Cecil  Group 


2004),  which  originated  in  CLU  [Liskov  et  al.  1977  Liskov  [19^  Liskov  and  Wing||i993 1  and 


also  appear  in  Theta  [Liskov  et  al.  1994  Day  et  al.  1995)  and  PolyJ  (Bank  et  al.|i997j.  Of  these 


languages,  only  Cecil  supports  external  or  multimethod  dispatch. 

Strongtalk  presents  a  structural  type  system  for  Smalltalk  and  also  supports  named  subtyp¬ 
ing  relationships  through  its  “brand”  mechanism  j  Bracha  and  Griswold  1993) .  However,  it  is 
not  possible  to  define  subtyping  on  brands.  Additionally,  since  it  is  a  type  system  for  Smalltalk, 
it  supports  only  the  single  dispatch  model. 

The  Modula-3  type  system — from  where  I  borrowed  the  term  “brand” — has  structural  types 
with  branding,  but  not  structural  snhtyping  \  Nelson  1991) .  That  is,  its  type  system  will  treat  two 
record  types  as  equivalent  if  they  have  the  same  structure  but  different  type  aliases,  but  does  not 
recognize  one  as  a  subtype  of  the  other  if  it  has  additional  fields.  The  object-oriented  part  of  the 
language  solely  uses  nominal  subtyping. 

Other  researchers  have  considered  the  problem  of  integrating  nominal  and  structural  sub¬ 
typing.  Reppy  and  Turon  have  addressed  the  problem  in  the  context  of  typechecking  traits 
|Reppy  and  Turon  2007) .  Their  resulting  type  system  is  a  hybrid  of  nominal  and  structural  sub¬ 
typing.  However,  in  their  system,  structural  types  are  second-class;  they  apply  to  trait  functions 
but  not  to  expressions  or  ordinary  functions.  Consequently,  there  is  less  expressiveness  as  com¬ 
pared  with  Unity:  it  is  not  possible  to  constrain  the  argument  of  a  function  to  have  particular 
members,  for  example.  Bono  et  al.  have  also  proposed  a  type  system  that  includes  both  nominal 


and  structural  aspects,  but  their  system  does  not  fully  integrate  the  two  disciplines  [Bono  et  al. 


2007) .  The  system  only  uses  structural  typing  when  typechecking  uses  of  the  this  variable  within 


a  class,  making  their  system  considerably  less  expressive  than  Unity. 


In  the  C++  concepts  proposal,  concepts  can  be  either  nominal  or  structural  j  Gregor  et  al. 


20o6|.  However,  concepts  apply  only  to  template  constraints,  not  to  the  subtyping  relation;  in 


this  way  they  are  similar  to  the  “where”-clause  constraint-based  polymorphism  described  above. 

ML  signature  matching  ]Milner  et  al.|i99^  is  structural  (rather  than  nominal),  and  as  noted 
by  Pierce  and  Harper  |Pierce||20^|,  the  design  considerations  of  structural  vs.  nominal  matching 
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are  very  similar  to  those  that  arise  when  comparing  structural  vs.  nominal  subtyping. 

Various  calculi  representing  the  ML  module  system  distinguish  between  external  labels  and 
internal  bound  variables  [Harper  and  Lillibridge||i994|  Harper  and  Stone]|20oo|.  This  is  some¬ 
what  analogous  to  the  Unity  distinction  between  simple  and  qualified  names,  though  the  mo¬ 
tivation  is  different.  In  ML,  internal  bound  variables  may  be  a-renamed,  while  external  labels 
may  not.  As  this  is  purely  a  static  concept,  there  is  no  notion  of  a  runtime  “mapping”  from  labels 
to  variables. 


5.2  Retroactive  Abstraction 

Supporting  retroactive  abstraction  in  a  nominally-typed  language  is  a  troublesome  issue,  par¬ 
ticularly  its  interaction  with  modular  typechecking  and  compilation. 


Global  analyses.  The  approach  of  some  languages  is  to  give  up  on  modularity  entirely,  and 
perform  whole-program  typechecking  and  compilation.  This  does  provide  some  expressiveness 
advantages,  but  I  believe  these  are  far  outweighed  by  the  inherent  scalability  issues. 

Examples  of  such  languages  are  Cecil  (Chambers  and  the  Cecil  Group||2004|  and  Aspect} 
(Kiczales  et  al.  2001 1.  Cecil  has  a  clean  separation  of  sub  typing  and  inheritance  and  uses  nom¬ 


inal  subtyping.  New  subtyping  relationships  can  be  declared  post-hoc,  as  can  inheritance  rela¬ 
tionships  (via  “extension  declarations”).  This  essentially  adds  new  tags  to  objects  after-the-fact. 
Such  new  inheritance  relationships  can  affect  the  exhaustiveness  and  ambiguity  checking  of 
multimethods,  a  problem  that  is  made  tractable  in  Cecil  due  to  its  whole-program  approach. 
Similarly,  the  whole-program  analysis  ensures  that  subtyping  relationships  (where  there  are  no 
runtime  tags  involved)  are  consistent  throughout  the  program. 

Aspect}  allows  inter-type  declarations,  which  allow  new  subtyping  relationships  (either 
extends  or  implements)  to  be  added  post-hoc  (Kiczales  et  al. 


2001 


This  feature  also  allows 
adding  methods  to  existing  objects,  which  is  similar  in  spirit  to  external  methods.  However, 
the  added  flexibility  of  these  features  comes  at  the  cost  of  whole- program  typechecking  and 
compilation,  the  later  which  is  achieved  by  “weaving”  aspect  declarations  into  the  classes  they 
extend. 


Transitivity  of  subtyping.  As  modularity  was  an  explicit  design  goal  of  this  dissertation,  I 
shall  focus  on  work  that  attempts  to  reconcile  modularity  and  retroactive  abstraction.  Unfortu¬ 
nately,  it  happens  that  there  is  a  fundamental  tension  between  retroactive  (nominal)  interface 
extension  and  modular  compilation  and  typechecking. 

First,  to  retroactively  change  a  nominal  subtype  hierarchy,  one  must  either  abandon  modular 
typechecking  or  change  the  subtype  relation  so  that  it  is  not  transitive  |  Ostermann|20o8[ .  To  see 
why,  suppose  that  we  have  definitions  of  interfaces  /,  /,  and  K,  each  with  no  declared  relationship 
to  the  other.  Now  we  add  a  retroactive  declaration  (outside  of  the  definition  of  /)  that  J  <  ■  I,  and 
another  declaration  (outside  of  the  definition  of  K)  that  K  <  :J.  With  these  declarations  in  place, 
the  transitivity  of  subtyping  gives  us  that  K  <:  I.  But,  to  establish  this  fact,  the  typechecker  must 
know  that  1)  that  it  should  use  /  as  the  intermediary  type,  2)  it  should  use  the  declaration  K  <:  J, 
and  3)  that  it  should  use  the  declaration  J  <:  I.  But,  the  property  to  be  proved,  K  <:  I,  does  not 
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mention  /  at  all,  nor  is  there  any  mention  of  /  in  the  definitions  of  K  and  /.  Since  /  may  have 
any  number  of  retroactive  subtypes,  this  means  that  the  typechecker  must  know  of  all  subtypes 
of  / — a  global  assumption.  Put  another  way:  to  be  modular,  the  typechecker  cannot  try  to  find 
the  relationship  /  c  /,  but  at  the  same  type  it  must  be  able  to  use  K  <:J  as  the  intermediary  step 
in  establishing  that  K  <■  I. 

This  problem  does  not  arise  in  Java-like  languages,  precisely  because  the  type  hierarchy  can¬ 
not  be  retroactively  changed.  To  establish  that  K  <:  I,  the  typechecker  simply  follows  the  de¬ 
clared  subtyping  relations  from  K  up  to  /.  At  no  point  does  the  typechecker  need  to  produce  an 
intermediary  type  that  has  not  been  explicitly  declared  as  a  supertype  in  the  definition  of  some 
type  along  the  way. 

If  retroactive  abstraction  is  limited  in  some  way,  it  can  be  compatible  with  modular  type¬ 
checking.  For  example,  Sather  |  Szyperski  et  al.lig^j)  allows  a  new  interface  to  declare  its  imple¬ 
menting  classes,  but,  for  the  sake  of  modular  typechecking,  this  interface  cannot  be  declared  as 
extending  some  other  interface  [Stoutamire  and  Omohundro||i996|. 

The  language  FJc  addresses  this  problem  by  allowing  flexible  retroactive  abstraction  but 
changing  the  subtype  relation  so  that  it  is  not  transitive  |  Ostermann||20o8  \ .  In  particular,  the 
programmer  must  manually  provide  a  set  of  “witness”  types  so  that  the  typechecker  can  apply 
subsumption.  In  this  example,  the  programmer  would  have  to  first  up-cast  id  to  /  then  up-cast  / 
to  /  so  that  the  typechecker  would  see  the  desired  relationship  between  K  and  /.  As  transitivity  is 
very  fundamental  to  subtyping,  I  believe  this  approach  could  be  non-intuitive  for  programmers. 


Tagged  interfaces.  The  situation  is  exacerbated  with  tagged  interfaces.  Recall  from  Sect.  ED 
that  I  have  defined  an  interface  as  a  set  of  methods  along  with  their  types.  Languages  with 
nominal  subtyping  have  nominal  interfaces;  these  are  analogous  to  Unity  “type”  abbreviations — 
with  the  additional  restriction  that  a  relationship  between  a  class  C  and  a  nominal  interface  / 
must  be  explicitly  stated  in  order  for  objects  of  class  C  to  conform  to  type  /.  “Interfaces”  with 
associated  tags  that  can  be  used  for  dispatch  (e.g.,  Java  and  C#  interfaces)  are  termed  “tagged 
interfaces.” 

Serious  complications  can  arise  when  there  is  retroactive  interface  extension  with  tagged 
interfaces,  as  this  allows  programs  to  dispatch  on  the  generated  tags.  In  Java,  for  instance,  pro¬ 
grammers  may  perform  “instanceof’  tests,  and  Java  extensions  allow  other  forms  of  interface 
dispatch  (e.g.,  predicate  dispatch  in  JPred;  multimethods  in  Nice  [Bonniot  2007 1,  Relaxed  Mul- 
tijava  iMillstein  et  al.|^003|,  and  JavaGI  |Wehr  et~aL  2007  Wehr  and  Thiemann]  2009 1).  Of 
these,  only  JavaGI  permits  both  retroactive  interface  extension  and  multiple  dispatch,  but  this 
approach  is  inherently  at  odds  with  modular  typechecking.  In  particular: 


1.  In  the  case  where  two  nominal  types  have  identical  members,  it  would  be  useful  to  specify 
that  the  types  should  be  considered  equivalent  (i.e.,  each  is  a  subtype  of  the  other).  Un¬ 
fortunately,  this  is  quite  problematic,  as  it  would  make  the  subtyping  relation  cyclic.  This, 
in  turn,  causes  problems  for  external/multimethod  ambiguity  checking. 

2.  It  is  unclear  whether  the  retroactive  extensions  should  have  global  or  lexical  scope.  Nei¬ 
ther  approach  is  satisfactory.  Suppose  that  class  B  implements  h.  In  module  Mi,  we  define 
a  multimethod  m  that  has  a  default  case  for  class  Object,  a  specialized  case  bi  for  A,  and  a 
specialized  case  bz  for  some  other  interface  A.  At  this  point,  the  call  m{r\ew  B{))  would 
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execute  hi.  Now,  suppose  that  in  a  new  module  M2,  we  add  the  declaration  B  implements 

h- 

•  With  globally-scoped  retroactive  extension,  we  must  either  perform  global  type¬ 
checking,  or  allow  some  errors  to  be  deferred  to  runtime  (JavaGI  takes  the  latter 
approach).  If  the  new  implements  declaration  has  global  scope,  the  call  to  m(new 
B{))  is  now  ambiguous.  Worse,  in  a  new  module  M3,  a  programmer  could  define 
I2  extends  li.  Now  the  call  is  no  longer  ambiguous,  but  the  behavior  of  the  program 
has  changed — ^2  is  now  executed! 

•  If  retroactive  extensions  are  locally  scoped,  this  produces  very  odd  subtyping  seman¬ 
tics.  In  particular,  what  should  happen  if  a  module  N  that  imports  both  Q  and  C2 
and  calls  m  with  a  B  object?  Within  Ci,  B  ^  I2,  but  within  D,  B  <  I2.  If  the  intended 
semantics  is  that  b2  should  be  executed,  then  within  b2,  B  <dynamic  but  (statically), 
Bihl 

I  believe  the  root  of  these  problems  is  that  here  the  tag  hierarchy  (on  which  dispatch  can  be  per¬ 
formed)  and  the  type  hierarchy  (used  for  subtyping)  have  been  conflated.  If  the  intended  purpose 
of  retroactive  interface  extension  is  to  make  a  class  compatible  with  a  particular  interface  for  the 
purposes  of  code  reuse  (e.g.,  to  pass  objects  of  the  class  to  a  library  method),  then  it  is  unclear 
why  there  should  be  runtime  tags  associated  with  interfaces.  On  the  other  hand,  if  it  is  useful  to 
allow  dispatch  on  a  hierarchy  supporting  multiple  inheritance,  one  wonders  (a)  why  these  two 
concepts  are  not  cleanly  separated  in  these  language  designs  and  (b)  if  the  added  convenience 
of  retroactive  tag  extension  is  worth  the  increase  in  complexity  and  reasoning  ability. 

To  my  knowledge,  there  is  no  type  system  with  modular  typechecking,  a  transitive  nomi¬ 
nal  subtype  relation,  and  retroactive  (tagged/untagged)  interface  extension  (where  new  nomi¬ 
nal  super-  and  sub-interfaces  can  be  retroactively  added).  Unity  sidesteps  these  issues  with  a 
clear  separation  between  tag  (i.e.,  brand)  and  type,  and  by  disallowing  dispatch  on  the  structural 
component  of  a  type. 


5.3  External  and  Multimethod  Dispatch 


External  and  multimethod  dispatch  has  been  extensively  studied,  but  in  the  context  of  either 
dynamically  typed  languages  or  languages  with  a  purely  nominal  type  system.  Among  the  dy¬ 


1997 


Feinberg  et  al.|  1997 1. 


namically  typed  languages  are  Common  Lisp  [Steele,  Jr(]|i990  Paepcke  1993)  and  Dylan  jShalit 


Some  languages  statically  ensure  that  multimethod  dispatch  is  exhaustive  and  unambiguous, 
but  require  that  the  entire  program  be  available  at  compile-time.  Examples  of  such  languages 
include  Cecil  |Chambers||i992  Chambers  and  the  Cecil  Group|2004|,  Tuple  | Leavens  and  Mill- 


stein 


998 1,  and  the  Java  extension  Nice  |Bonniot||2007|. 


More  recent  work  has  focused  on  modular  typechecking  of  external  methods  and  multi¬ 
methods,  as  well  as  the  problem  of  integrating  external  methods  into  existing  languages;  this 


includes  the  Dubious  calculus  (System  M),  Multijava  [Millstein  and  Chambers 


2002 


Clifton 


et  al.|200^  and  EML  [Millstein  et  aHao^  2004 1.  I  have  built  on  these  existing  techniques  for 
modular  typechecking  of  external  methods. 
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The  language  A&  jCastagna  et  al.  1995)  includes  multimethod  dispatch  and  includes  struc¬ 
tural  sub  typing  on  methods,  similar  to  Unity.  However,  the  sub  typing  relation  for  object  types 
(i.e.,  classes)  uses  only  nominal  subtyping,  in  contrast  to  Unity. 

Case  classes  in  Scala  |Odersky|2007|  can  be  used  to  obtain  some  of  the  benefits  of  external 
dispatch,  but  they  are  mainly  useful  for  ML-style  pattern  matching.  New  functions  can  be  added 
that  perform  case  analysis  on  a  case  class  hierarchy,  but  the  signatures  of  the  case  classes  do  not 
change  as  with  external  methods.  Scala  case  classes  can  either  be  sealed,  in  which  case  all  cases 
must  appear  in  the  same  compilation  unit;  otherwise  they  are  extensible. 

Finally,  it  is  worth  noting  that  a  language  supporting  only  external  or  multimethod  dispatch 
(without  structural  subtyping  or  constraint-based  polymorphism  features)  would  lack  the  de¬ 
sired  expressiveness.  That  is,  retroactive  abstraction  of  some  form  is  necessary  to  solve  the 
problems  outlined  in  Chapter  [^(e.  g.,  Fig.lT^. 


5.4  Multiple  Inheritance 


Here  I  describe  related  work  that  was  not  previously  discussed  in  Sections 
Some  uses  of  multiple  inheritance  can  be  encoded  using  virtual  classes  \ 

3.3  and  3-8 

Madsen  and  Moller- 

Pedersen||i989|  Thorup||i997)  or  nested  inheritance  |  Nystrom  et  al.||2004| 

20o6|.  (For  the  pur- 

poses  of  this  comparison,  the  differences  between  the  two  features  are  not  particularly  relevant; 
I  use  the  newer  “nested  inheritance”  terminology,  however.)  In  languages  with  such  features 
(e.g..  Beta,  Jx,  J&),  a  class  C  may  define  one  (or  more)  nested  classes  D.  When  a  new  class  E 
extends  C,  it  inherits  all  of  C’s  members,  including  the  nested  classes  D.  As  with  ordinary  in¬ 
heritance,  the  meaning  of  C’s  code  is  different  in  the  context  of  E,  and  E  may  override  any  of 
C’s  members — including  the  nested  classes  D.  When  a  nested  class  Di  is  overridden  in  the  new 
class  E,  the  new  definition  enhances,  rather  than  replaces,  the  old  definition.  Additionally,  E.Di 
is  a  subclass  (and,  in  nested  inheritance,  a  subtype)  of  C.Di. 

As  extensively  detailed  by  Nystrom  et  al.  |Nystrom  et  al. 


2004 


20o6|,  this  latter  feature 


provides  powerful  code  reuse  capabilities  that  are  analogous  to,  but  more  powerful  than,  mixins. 
A  particular  strength  of  virtual  classes  and  nested  inheritance  is  the  ability  to  reuse  code  across 
multiple  related  classes.  Additionally,  some  uses  of  external  methods  can  be  encoded  using  these 
language  features,  with  the  interesting  difference  that  the  original  classes  (to  which  the  external 
methods  have  been  added)  and  the  “new”  classes  induced  by  these  additions  can  co-exist  in  the 
same  program  in  the  virtual  class/nested  inheritance  encoding.  Depending  on  the  context,  such 
a  semantics  could  be  useful.  For  these  reasons,  I  view  virtual  classes  and  nested  inheritance  as 
features  that  are  complimentary  to  my  multiple  inheritance  design,  despite  the  fact  that  these 
designs  do  aim  to  solve  the  common  problem  of  code  reuse).  Additionally,  to  the  best  of  my 
knowledge,  there  is  no  language  that  combines  virtual  classes/nested  inheritance  and  external 
dispatch. 

Cecil  |Chambet^|i992  Chambers  and  the  Cecil  Group||2004|  also  provides  both  multiple 
inheritance  and  multimethod  dispatch,  but  it  does  not  include  constructors  (and  therefore  pro¬ 
vides  ordinary  dispatch  semantics  for  methods  acting  as  constructors),  and  it  performs  whole- 
program  typechecking. 
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JavaGI  allows  multiple  dispatch  on  interfaces,  but  performs  class-load-time  checking  to  de¬ 


tect  any  conflicts  that  may  arise  |  Wehr  et  al. 

2007 

Wehr  and  Thiemann|2009|. 

Like  JPred,  the  language  Half  &  Half 

Baumgartner  et  al.||2002|  provides  multimethod  dis 

patch  on  Java  interfaces.  In  this  language,  if  there  exist  specialized  method  implementations  for 
two  incomparable  interfaces  A  and  B,  the  visibility  of  one  of  the  two  interfaces  must  be  package- 
private.  Like  System  M,  this  effectively  disallows  multiple  (interface)  inheritance  across  module 
boundaries  (where  a  package  is  a  module).  Half  &  Half  does  not  consider  the  problem  of  multiple 
inheritance  with  state. 

Pirkelbauer  et  al  have  considered  the  problem  of  integrating  multimethods  into  C++,  which 
is  especially  difficult  due  to  existing  rules  for  overload  resolution  |  Pirkelbauer  et  al.  2007) .  How¬ 
ever,  this  proposal  is  not  modular;  because  of  the  potential  for  inheritance  diamonds,  the  design 
requires  link-time  typechecking. 

Note  that  it  is  possible  to  modify  the  semantics  of  multimethod  dispatch  so  that,  by  defini¬ 
tions,  ambiguities  cannot  arise  in  the  presence  of  multiple  inheritance.  A  language  may  linearize 
the  class  hierarchy  (e.g.,  CLOS  |Bobrow  et  al.|i988 1,  [Agrawal  et  al.|i99T))  or  choose  the  appro¬ 
priate  method  based  on  textual  ordering  fBoyland  and  Castagna|i997 1 .  However,  such  semantics 
can  be  fragile  and  confusing  for  programmers. 


5.5  Empirical  Studies 


As  mentioned  in  Sect.  [4. 3)  researchers  have  studied  the  problem  of  refactoring  programs  to  use 
most  general  nominal  types  where  possible  |  Forster  2006)  Steimann|2007| .  Structural  subtyping 
would  make  such  refactorings  more  feasible  (since  new  types  would  not  have  to  be  defined)  and 
applicable  to  more  type  references  in  the  program  (since  structural  supertypes  for  library  types 
could  be  created,  while  new  interfaces  cannot). 

Muschevici  et  al.  measured  the  number  of  cascading  instanceof  tests  in  a  number  of  Java  pro¬ 
grams,  to  determine  how  often  multiple  dispatch  might  be  applicable  |Muschevici  et  al.  2008). 
They  found  that  cascading  instanceof  tests  were  quite  common,  and  that  many  cases  could  be 
rewritten  to  use  multimethods;  this  is  consistent  with  my  results. 

Corpus  analysis  is  commonly  used  in  empirical  software  engineering  research.  For  example, 
it  has  been  used  to  examine  non-nullness  [Chalin  and  James]|2007|,  aspects  |Baldi  et  al.|20o8|, 
micro-patterns  |Gil  and  Maman||2005|,  and  inheritance  [Tempero  et  al.  20^. 
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Chapter  6 
Conclusions 


There  was  a  point  to  this  story,  but  it  has  temporarily  escaped  the 
chronicler’s  mind. 

Douglas  Adams  {The  Hitchhiker’s  Guide  to  the  Galaxy) 


1.4 


The  previous  chapters  have  each  provided  evidence  to  support  the  hypotheses  listed  in  Sect. 

In  this  chapter,  I  describe  in  additional  detail  how  each  hypothesis  has  been  validated,  and  how 
the  hypotheses,  taken  together,  support  the  main  thesis  of  this  dissertation.  Additionally,  I  dis¬ 
cuss  potential  limitations  of  the  work  as  well  as  directions  for  future  work. 


6.1  Validation 

Recall  the  thesis  statement  of  Sect.|i.4| 

An  object-oriented  programming  language  can  provide  integrated  support  for  (a) 
external  dispatch,  (b)  nominal  subtyping  (c)  structural  subtyping  and  (d)  multiple 
inheritance — all  without  sacrificing  modular  typechecking  These  richer  structuring 
mechanisms  can  serve  to  make  code  more  reusable  and  adaptable. 

The  main  thesis  is  supported  by  seven  hypotheses,  each  of  which  is  directly  testable.  There  are 
two  main  types  of  hypothesis:  those  concerning  modular  typechecking  and  those  concerning 
the  language’s  expressiveness.  The  former  type  of  hypothesis  is  supported  through  the  Unity 
language  design  and  proof  of  type  safety  and  the  latter  type  is  supported  through  a  combination 
of  examples  and  empirical  studies. 


6.1.1  Modularity  and  Type  Safety 

As  described  in  Chapters  and  the  four  main  features  of  Unity,  i.e,  features  (a)-(d),  have 
interesting  interactions  with  one  another.  For  instance,  as  illustrated  in  Sect.|2.2.^  a  naive  com¬ 
bination  of  structural  subtyping  and  external  dispatch  would  result  in  serious  problems  for  am- 
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biguity  checking  of  external  methods.  Additionally,  such  a  semantics  could  cause  a  program’s 
behavior  to  be  altered  by  the  presence  or  absence  of  particular  methods,  which  could  in  turn 
produce  subtle  bugs  related  to  accidental  subtyping. 

Similarly,  if  typechecking  is  to  be  modular,  combining  external  dispatch  and  multiple  inher¬ 
itance  is  non-trivial,  the  heart  of  the  issue  being  the  so-called  “diamond  problem.”  As  described 
previous  languages  that  include  both  of  these  features  either  restrict  expressiveness 


3-3 


in  Sect. 

or  require  that  the  programmer  provide  an  exponential  number  of  disambiguating  methods. 
Neither  of  these  solutions  is  satisfactory. 

Consequently,  two  hypotheses  directly  address  type  safety  and  modular  typechecking: 


Hypothesis]^  A  language  with  synergy  between  structural  subtyping  and  external  dispatch  can 
be  achieved  through  a  novel  combination  of  structural  and  nominal  subtyping. 


Hypothesis  |V|  Through  the  use  of  a  novel  multiple  inheritance  scheme,  modular  typecheck¬ 
ing  can  be  performed  in  a  language  with  multiple  inheritance  and  external  dispatch,  without 
requiring  programmer-specified  disambiguating  methods. 


The  evidence  for  these  two  hypotheses  is  the  full  Unity  language  design  (presented  in  Sec¬ 
tions  and  [3]^,  the  proof  of  type  safety  of  the  formal  system  (outlined  in  Sect.  3.7.4  and  pre¬ 


sented  in  Appendix]^,  and  the  detailed  argument  of  modularity  of  the  formal  system  (presented 
in  Sect.|3.7.3|. 


6.1.2  Expressiveness 

Designing  a  language  is  one  matter,  but  designing  a  useful  language  is  another  matter  entirely. 
Thus,  five  of  the  seven  hypotheses  concern  the  expressiveness  and  potential  utility  of  the  pre¬ 
sented  language  design. 


Hypothesis  By  providing  retroactive  abstraction,  structural  subtyping  can  be  used  to  im¬ 
prove  the  reusability  and  maintainability  of  existing  object-oriented  programs. 


This  hypothesis  is  supported  through  the  empirical  studies  described  in  Chapter]^  In  particu¬ 
lar,  Sect.|4.3|presented  evidence  from  a  global  analysis  that  inferred  structural  types  for  method 
parameters  in  Java  programs.  Quantitative  analysis  determined  that  many  method  parameters 
were  overly  precise,  while  qualitative  analysis  determined  that,  more  often  than  not,  it  would  be 
useful  to  generalize  such  method  parameters.  Since  nominal  subtyping  is  at  odds  with  retroac¬ 
tively  implementing/extending  existing  interfaces  (described  in  Sect.  1.2  and  in  more  detail  in 
Sect.  I5.2I  and  such  a  capability  would  be  necessary  when  using  types  defined  in  libraries,  it 


follows  that  structural  subtyping  would  be  beneficial  in  these  situations.  In  particular,  program¬ 
mers  could  use  structural  types  for  method  parameters,  increasing  their  potential  for  reuse  (as 
any  object  with  a  structurally-conforming  implementation  could  passed  in  as  the  actual  parame¬ 
ter).  Additionally,  the  study  showed  that  it  is  infeasible  to  define  new  (nominal)  interfaces  where 
possible;  this  strategy  would  result  in  4.1  times  as  many  interfaces  in  the  resulting  program,  as 
compared  to  the  original. 


6.1.  Validation 
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The  study  in  Sect  4.5.1  found  a  high  frequency  of  common  methods  (methods  with  the  same 


name  and  signature,  but  that  are  not  contained  in  a  common  supertype  of  the  enclosing  classes), 
and  a  low  frequency  of  common  methods  that  represent  an  accidental  name  clash  (Sect  4.5. 2|. 
Having  common  methods  between  two  classes  may  indicate  a  missed  opportunity  for  abstrac¬ 
tion,  which  could  be  solved  using  structural  subtyping  for  retroactive  abstraction.  Finally,  a 
complementary  study  found  that  common  methods  could  result  in  code  clones  of  a  particular 
nature  (Sect. [4^5^. 


Hypothesis  III  Existing  language  designs  can  lead  to  coding  patterns  that  defer  errors  to  run¬ 


time;  structural  subtyping  could  provide  more  static  typechecking  in  these  situations  by  allowing 
programmers  to  encode  more  properties  directly  in  the  type  system. 


This  hypothesis  is  again  supported  by  empirical  studies  in  Chapter  In  particular,  I  pre¬ 
sented  quantitative  and  qualitative  data  showing  that  some  Java  runtime  exceptions  (i.e., 
OperationUnsupportedException)  can  be  eliminated  in  a  straightforward  manner  with  a  design 
that  uses  structural  subtyping  (Sect.  [4^.  Additionally,  another  study  found  that  some  uses  of 
Java  reflection  can  be  converted  to  uses  of  structural  subtyping  (Sect.  [4^. 


Hypothesis  [Iv]  The  combination  of  structural  sub  typing  and  external  dispatch  has  the  syner¬ 
gistic  effect  of  providing  an  expressive  form  of  retroactive  abstraction. 


This  hypothesis  is  supported  in  two  ways,  the  first  being  a  series  of  illustrative  examples  in 
In  particular,  the  examples  showed  that  structural  subtyping  allows  defining  abstract 
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Sect. 

interfaces  and  external  dispatch  allows  programmers  to  add  new  methods  in  order  to  make  ex¬ 
isting  brands  conform  to  those  interfaces. 

Next,  the  empirical  study  described  in  Sect.  4.6  showed  that  many  cases  of  cascading 
instanceof  tests  in  Java  programs  may  be  re-written  using  a  combination  of  structural  subtyping 
and  external  methods.  Such  a  re-writing  has  many  code  reuse  benefits,  as  it  allows  an  existing 
class  to  be  adapted  to  a  new  context. 


Hypothesis|VI[  A  language  can  be  designed  with  a  new  form  of  multiple  inheritance — multiple 
inheritance  without  diamonds — a  design  that  provides  more  opportunities  for  code  reuse  and 
that  is  more  expressive  than  other  proposed  alternatives  to  full  multiple  inheritance  (i.e.,  multi¬ 
ple  interface  inheritance,  mixins,  and  traits). 

This  hypothesis  is  validated  by  the  Unity’s  multiple  inheritance  design  (Chapter  [H  as  well  as  a 
detailed  comparison  to  other  language  designs  in  the  context  of  the  Unity  AST  nodes  example 
(Sect.  [HI-  In  particular,  I  showed  that  each  of  multiple  interface  inheritance,  mixins,  traits  and 
Scala  traits  are  less  expressive  than  Unity,  along  the  dimensions  I  identified.  Multiple  interface 
inheritance  does  not  allow  multiple  inheritance  of  code,  mixins  do  not  allow  one  mixin  to  inherit 
from  another,  and  (traditional)  traits  do  not  allow  defining  state. 

Scala  traits  (which  are  a  fusion  of  “ordinary”  traits  and  mixins)  are  discussed  in  Sect. 

The  limitation  of  Scala  traits  is  that  their  constructors  may  not  take  parameters  (because  of  the 
potential  for  diamond  inheritance),  while  Unity  need  not  place  such  a  restriction.^  Additionally, 
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^Though  the  core  calculus  does  not  explicitly  include  constructors,  their  formalization  is  straightforward 
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if  multiple  dispatch  or  external  dispatch  were  added  to  Scala,  a  strategy  like  that  of  JPred  or 
Fortress  would  be  necessary  for  ensuring  unambiguity  of  multimethods/external  methods. 


Hypothesis|VII  By  converting  inheritance  diamonds  to  inheritance  dependencies  and  subtyp¬ 
ing  among  abstract  classes  (via  a  requires  clause),  a  program  with  inheritance  diamonds  can  be 
systematically  translated  into  a  program  with  multiple  inheritance  but  without  any  inheritance 
diamonds. 


This  hypothesis  is  supported  by  the  real-world  examples  in  Sect.  3.6  which  shows  how  C++  in¬ 
heritance  diamonds  can  be  systematically  translated  to  Unity.  While  I  have  presented  examples 
from  only  two  programs,  I  found  at  least  5  other  (less  interesting)  inheritance  diamonds  in  two 
other  applications. 

With  regard  to  supporting  this  hypothesis,  I  believe  a  more  systematic  study  of  inheritance 
diamonds  in  C++  would  not  be  especially  worthwhile.  Such  a  study  could  be  interesting  in 
its  own  right,  but  its  value  would  mostly  lie  in  characterizing  the  nature  of  C++  inheritance 
diamonds  and  quantifying  how  often  concrete  classes  appear  on  the  “sides”  of  the  inheritance 
diamond  (as  the  corresponding  Unity  translation  would  require  converting  this  to  an  abstract 
class). 


Instead,  the  real-world  examples  of  Sect.  3.6  show  that  a)  C++  programmers  do  make  use 
of  diamond  inheritance,  b)  there  exist  such  uses  that  are  “reasonable,”  and  (c)  in  some  cases, 
the  Unity  translation  is  particularly  trivial  (when  new  concrete  classes  are  not  needed).  The 
translation  itself  (outlined  in  Sect.  3.6. i|  is  so  straightforward  that  I  see  little,  if  any,  research 
contribution  in  its  implementation. 


6.2  Future  Directions 

The  Unity  design  is  not  without  its  limitations.  In  particular,  since  a  full  implementation  does 
not  yet  exist,  it  is  quite  conceivable  that  additional  research  problems  could  arise  when  imple¬ 
menting  Unity  as  a  general-purpose  language.  In  this  section,  I  outline  several  directions  for 
future  work. 


6.2.1  Efficiency 


It  is  unknown  whether  Unity  code  would  be  sufficiently  efficient.  This  is  tempered  somewhat  by 
the  “pay-as-you-go”  property  of  the  language  with  regard  to  structural  subtyping.  That  is,  the 
name  mapping  dictionary  is  created  only  when  structural  types  are  explicitly  needed.  But,  as  I 
advocate  a  relatively  high  use  of  structural  subtyping,  the  average  execution  overhead  of  method 
invocation  may  be  quite  high,  in  the  absence  of  appropriate  optimizations. 

Of  course,  one  should  not  underestimate  the  cleverness  of  those  creating  compilers,  includ- 

J|20(^ 


ing  “just-in-time”  (JIT)  compilers.  The  Whiteoak  language,  for  example  |GiI  and  Maman 


has  achieved  an  acceptable  level  of  performance  by  using  a  wrapper-generation  mechanism  for 
invoking  structurally-typed  methods.  Additionally,  Microsoft  is  actively  supporting  an  effort  to 


and  they  are  orthogonal  to  the  issues  under  consideration. 
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integrate  Ruby  and  Python  into  .NET,  which  is  partly  achieved  by  implementing  a  dynamic  lan¬ 
guage  runtime  (DLR)  on  top  of  the  regular  common  language  runtime  (CLR)  [Microsoft  2009b|. 
The  DLR,  among  other  things,  greatly  eases  the  task  of  creating  an  efficient  compiler  for  such 
dynamic  languages,  and  includes  functionality  such  as  a  shared  dynamic  type  system  and  ef¬ 
ficient  generation  of  symbol  tables  |Chiles||2007|.  C#  4.0  will  also  support  a  dynamic  keyword 
that  allows  tagging  some  objects  as  dynamically  typed  |Microsoft  2009a|.  On  such  objects,  the 
typechecker  will  allow  any  method  to  be  called  and  checking  the  existence  of  the  method  is  de¬ 
ferred  to  runtime.  While  the  merits  of  such  a  feature  are  debatable  (and  are  mostly  related  to 
orthogonal  issues  such  as  importing  dynamically  linked  libraries),  its  inclusion  highlights  the 
need  for  efficient  dictionary-based  method  invocation. 

In  essence,  I  argue  that  it  is  quite  conceivable  that  one  could  implement  a  Unity  compiler  that 
targets  the  DLR  and  achieves  acceptable  performance  for  method  invocation.  Implementing 
such  a  compiler,  is,  of  course,  relegated  to  future  work. 

finally,  it  is  quite  possible  that  some  applications  will  not  have  stringent  performance  de¬ 
mands.  Quite  a  large  amount  of  modern  code  is  written  in  dynamic  languages  such  as  JavaScript, 
Ruby  and  Python,  which  are  not  known  for  their  support  of  efficient  method  invocations. 


6.2.2  Structural  Downcasts 

With  the  availability  of  structural  subtyping,  programmers  may  also  wish  to  have  structural 
downcasts.  Such  a  feature  can  certainly  be  implemented,  but  it  may  be  difficult  to  implement 
efficiently.  It  remains  an  open  question  whether  structurally  typed  code  would  require  a  large 
number  of  structural  downcasts,  as  well  as  how  often  the  more  efficient  nominal  downcast  could 
be  used  instead. 


6.2.3  Blame  Assignment 


As  mentioned  in  Sect.  [5.2!  Ostermann  has  identified  an  important  property  of  nominal  sub¬ 
typing:  it  allows  a  useful  default  blame  assignment  [Ostermann  2008).  In  nominally  typed  lan¬ 
guages,  a  class’s  author  is  the  one  responsible  for  ensuring  that  the  class  is  adheres  to  the  sub¬ 
typing  relationships  induce  by  its  implements  clause.  In  contrast,  with  structural  subtyping,  it  is 
always  the  client  code’s  “fault”  when  a  subtype  relationship  does  not  hold,  and  the  error  message 
will  be  noted  at  that  point  in  the  code.  Ostermann  argues  that,  instead, /Zexffi/e  blame  assign¬ 
ment  is  key,  so  that  programmers  may  specify  who  is  responsible  for  maintaining  a  subtype 
relationship:  either  the  user  or  the  designer  of  a  component.  (Ostermann’s  language  f  J<:  allows 
such  flexible  blame  assignment.) 

As  a  concrete  example,  suppose  it  is  intended  that  brand  B  always  implement  interface  /. 
Type  abbreviations  in  a  Unity  implementation  would  allow  /  to  be  defined  in  a  single  location,  if 
desired,  and  used  systematically  throughout  the  program  with  the  name  /.  Now,  suppose  a  new 
method  m  is  added  to  this  single  type  abbreviation  /,  a  method  m  that  does  not  exist  in  B.  In 
a  nominally  typed  setting,  the  definition  of  B  would  be  at  fault,  since  it  has  declared  an  explicit 
relationship  to  /.  In  contrast,  in  a  structurally  typed  setting,  errors  would  appear  whenever 
there  was  made  an  attempt  to  coerce  an  object  with  brand  B  to  type  /.  In  this  example,  the 
error  message  has  appeared  in  the  “wrong”  location;  this  could  certainly  pose  serious  software 
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engineering  issues.  (In  fact,  the  designers  of  Strongtalk,  which  originally  had  both  nominal  and 
structural  subtyping  |  Bracha  and  Griswold  1993) ,  reverted  to  a  purely  nominal  system  in  later 
versions,  precisely  due  to  blame  assignment  in  error  messages  |Bracha||20o6|.) 

However,  I  do  not  believe  these  problems  are  insurmountable.  In  particular,  a  combination 
of  a  methodology  for  type  definitions  and  specialized  IDE  support  could  greatly  minimize  this 
problem.  It  is  possible  that  one  could  move  to  a  system  that  is  a  hybrid  of  Unity  and  Ostermann’s 
FJc  but  the  lack  of  transitive  subtyping  in  that  system  is  a  worrisome  issue. 


6.2.4  Error  messages 


Related  to  the  problem  of  blame  assignment  is  that  of  producing  readable  error  messages,  which 
is  generally  much  more  difficult  when  a  type  system  includes  any  structural  aspects  (which  in¬ 
cludes  designs  such  as  Java-like  generics).  The  problem  is  that  a  particular  structural  type  may 
have  more  than  one  corresponding  user-defined  type  abbreviation,  or — worse  yet — it  may  have 
no  such  abbreviation.  Such  “anonymous”  types  can  result  in  particularly  indecipherable  error 
messages,  a  problem  of  which  (for  example)  users  of  C++  templates  are  painful  aware.^ 

I  believe  this  problem  is  an  engineering  issue  at  heart,  as  it  is  impossible  to  “prove”  that  a 
particular  error  message  algorithm  is  “better”  than  others,  let  alone  that  it  is  “good.”  This  is  not 
to  downplay  the  difficulty  of  solving  the  problem,  but  rather  to  identify  what  I  believe  would  be 
a  tractable  approach.  This  problem  is  related  to  that  of  producing  “good”  type  inference  error 
messages  (e.g.,  |Wand|i986]  Beaven  and  Stansifer  1993[  Duggan  and  Bent|i996{  Tip  and  Dinesh 


200i|  Stuckey  et  al.|2003|),  and  it  is  possible  that  some  of  the  approaches  to  the  latter  problem 

could  inform  a  concrete  solution  to  our  error  message  problem. 


6.2.5  IDE  Support 


The  empirical  study  in  Sect.  4.3  found  that  method  parameters  are  often  overly  precise;  I  have 


argued  that  structural  subtyping  would  make  it  easier  to  generalize  these  parameters.  However, 
there  is  no  reason  to  assume  that  users  of  a  language  with  structural  subtyping  would  use  appro¬ 
priately  general  types  for  parameters.  Consequently,  it  could  be  quite  useful  to  generalize  the 
algorithm  of  the  Infer  Type  refactoring  [Steimann  2007 1  to  apply  in  a  structural  setting.  Such  a 
refactoring  would  be  even  more  powerful  in  a  language  with  structural  types,  as  the  refactoring 
would  be  able  to  suggest  types  that  are  supertypes  of  existing  library  types  (which  the  current 
refactoring  cannot,  as  it  applies  to  Java). 


6.3  Broader  Impact 


The  contributions  of  this  thesis  highlight  the  utility  and  importance  of  structural  subtyping  as  a 
typing  discipline.  I  have  shown  the  synergy  between  structural  subtyping  and  external  dispatch. 


^The  new  C++ox  concepts  proposal  would  improve  the  situation;  interestingly,  part  of  the  solution  in¬ 
volves  introducing  the  notion  of  “nominal”  vs.  “structural”  concepts  jGregor  et  al.  2006). 


6.3-  Broader  Impact 
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but  I  expect  that  an  analogous  synergy  can  be  achieved  when  integrating  structural  subtyping 
and  other  language  features. 

4-5.^ 


In  particular,  the  problem  of  accidental  subtyping  (discussed  in  Sections 


2.2.2 


and 


would  be  greatly  minimized  if  a  richer  type  system  were  used.  For  example,  if  one  were  to  use  a 
lightweight  form  of  pre-  and  post-conditions,  such  as  typestates  fStrom  and  Yemini||i986  Man 


Idelbaum  et  al.||2003|  |DeLine  and  Fahndrich||2004|  [BierhofF  and  Aldrich||2005  I2007I'  Kim  et  al. 


2009),  then  similarly- named  methods  that  perform  different  tasks  can  be  differentiated.  Sub¬ 


typing  between  typestates,  such  as  that  proposed  by  jBierhoff  and  Aldrichfapos  2007 1,  would 
be  particularly  useful  in  this  setting.  This  idea  could  be  extended  even  further  to  systems  that 
check  logical  predicates,  such  as  JML  [Leavens  et  al.  2006 1  or  Spec#  |  Barnett  et  al. 


2004 


2005 


Leino  2007).  In  such  a  setting,  subtyping  would  be  simply  become  logical  entailment;  i.e.,  type 


A  <  B  iff  A  implies  B. 

Another  potential  synergy  could  be  harnessed  when  using  co-  and  contravariant  declaration- 
site  type  parameters  along  with  structural  sub  typing.^  Suppose  co-  and  contravariant  type  pa¬ 
rameters  were  prefixed  with  “+”  or  respectively,  such  as  in  Scala  |Odersky|2007|.  Then,  co¬ 
variant  (or  contravariant)  version  of  an  interface  would  be  a  structural  supertype  of  the  invariant 
version  of  that  interface.  In  particular,  the  following  Scala  code  is  valid: 


trait  ReadableCell  [+T]  { 
def  get :  T ; 

} 

trait  WriteableCell  [-T]{ 
def  set(x:T)  :  Unit; 

} 


class  Cell  [T]  (init:T)  extends  ReadableCell[T]  with  WriteableCell[T]  { 
private  var  value:  T  =  init 
def  get:  T  =  value 
def  set(x:T):  Unit  =  {  value  =  x} 

} 

Here,  the  trait  ReadableCell  is  a  super-interface  of  Cell,  and  its  type  parameter  T  is  covariant. 
Similarly,  WriteableCell’s  type  parameter  is  contravariant.  Since  invariant  type  parametrization 
is  more  restrictive  than  either  co-  or  contravariant.  Cell’s  type  parameter  is  invariant. 

Here,  we  have  use  nominal  subtyping  and  set  up  explicit  relationships  between  Cell, 
ReadableCell,  and  WriteableCell.  With  structural  subtyping,  however,  we  could  retroactively  add 
the  types  SReadableCell  and  SWriteableCell  (making  them  structural  types  rather  than  traits)  and 
Cell  would  be  a  subtype  of  each  of  these. 


^Special  thanks  to  Nick  Benton  for  this  observation. 
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Appendix  A 
Unity  Type  Safety 


The  proof  of  the  pudding  is  the  eating. 
Miguel  de  Cervantes  Saavedra  {Don  Quixote) 


This  section  presents  the  full  type  safety  proof  that  was  outlined  in  Sect.  3. 7.4]  Definitions  and 
lemmas  that  were  originally  mentioned  in  Chapter  appear  here  with  new  numbering  (with 
backreferences  to  the  previously  stated  versions). 


A.i  Definitions 

Note  1.  The  sequence  C  is  shorthand  for  {C  where  #C  is  the  length  of  the  sequence  C. 

Definition  A.  1  (Context  consistency  relation  [Definition|3.3|). 

The  judgement  A  :  Z  is  defined  by  the  following  inference  rules: 

(Delta-Wf-Brand) 

Z  =  Zo,  brand  B{a',{qi  ■■  B{Mi)  =>  T;  extends  C  requires  D 
(Delta-Wf-Empty)  Aq  :  Zq  fieldTypej.  (D)  =  a 

this :  B(M,),  fields :  O' An  et  :t,-  (Vz  e  l..n) 

■  :  •  Ao,B(^,- =  ez extends  C  :  Z 

(Delta-Wf-Method) 

Z  =  Zo,  method  q[q :  Bi  {Mi)  =>  n  Aq  :  Zq 

this:Bz(Mz)  i-x  ei'-Ti  (Vzel..n) 

Ao,  method  ^(Bz.^  =  6; :  Z 


Definition  A. 2  (Well-formed  static  context  judgement). 
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The  judgement  Z  ok  is  defined  by  the  following  inference  rules: 

(Sigma-Wf-Base)  (Sigma-Wf-Decl) 

ded-type^^g^^g  ^  Z  Z  ok  Z  i-  ded-type  ok 

•  ok  Z,  ded-type  ok 

Definition  A. 3  (Field  type  plus  required  field  types). 

def  -  - 

fieldWithReqj;(B)  =  fieldTypej.(B)  a  Xr,  where  C  requires  D  e  Z  and  Xr  -  fieldTypej.(D). 

A. 2  Signature  Weakening  Lemmas 

This  section  contains  lemmas  that  prove  weakening  of  the  static  context  Z  for  various  judge¬ 
ments.  These  lemmas  are  used  in  both  the  progress  and  preservation  proofs.  Note  that  some 
auxiliary  strengthening  lemmas  are  needed;  this  is  because  the  negation  of  some  judgements  are 
used  (e.g.,  if 2  internal). 

Lemma  A.i  (No  duplicate  names  in  well-formed  contexts). 

If  Z  ok  then  all  brand  declarations  Bel.  and  all  external  method  family  declarations  q  el  are 
distinct  from  one  another. 

Proof.  Straightforward  induction  on  Z  ok.  □ 

Lemma  A.2  (Common  method  implies  common  ancestor  [Lemma[3.3|). 

If  Z  ok  and  mtype.^[q,B)  and  mtype^iq,  C]  then  there  exists  some  D  i=  Object  such  that  B'^iD 
and  C  Ex  D. 


Proof.  By  simultaneous  induction  on  the  two  mtype^  derivations,  using  the  no-duplicate- 
names  lemma  (Lemma|A.i|l,  the  constraints  on  owner  brands  (premises  (1)  and  (3)  of  Tp-Ext- 
Method),  and  the  fact  that  external  methods  cannot  override  internal  methods  (premise  (4)  of 
Tp-Ext-Method).  □ 

Lemma  A.3  (Weakening  for  sub-brand  judgement). 

If  Zq  ok  and  B  Exq  C  and  Z  ok  and  Z  3  Zq  then  B  Ex  C. 

Proof.  By  induction  on  B  Exq  C. 

case  Sub-Brand-Refl.  Immediate. 

case  Sub-Brand-Trans.  Straightforward  induction. 

case  Sub-Brand-Decl.  B(t;Q)  extends  Ci,...,C„  cZq 

By  the  definition  of  the  superset  relation,  Bel.  By  the  non-duplicate  entries  lemma 
(Lemma|A.i|,  Z  has  only  one  entry  for  B,  therefore  it  is  the  same  entry  as  that  in  Zq.  □ 
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Lemma  A.4  (Weakening  for  subtype  and  sub-row  judgements). 

1.  If  Zq  ok  and  i-^o  t<t'  and  Z  ok  and  Z  2  Zq,  then  \-z  t<  t' . 

1.  If  Zq  ok  and  i-^o  ra-  h  and  Z  ok  and  Z  2  Zq,  then  \-i  Va-  ta<ri,:  ti,. 


Proof.  By  mutual  induction  on  the  subtype  and  sub-row  derivations. 

1.  By  case  analysis  on  the  last  rule  used  in  the  derivation  i-Xq  t  <  f: 
case  Sub-Refl,  Sub-aLi,  Sub-aLj,  Sub-Type-Var.  Immediate. 

case  Sub-Trans,  Sub-Func,  Sub-aR,  Sub-Mu.  Straightforward,  using  induction  hypoth¬ 
esis  (1). 

case  Sub-Record.  Follows  from  induction  hypothesis  (2)  and  Sub-Record. 
case  Sub-Obj.  Follows  from  sub-brand  weakening  (Lemma  |A.3|,  induction  hypothesis 
(2),  and  Sub-Obj. 

case  Sub-Requires.  Follows  from  non-duplicate  brand  definitions  (Lemma  A.i  I,  the 
properties  of  set  inclusion,  induction  hypothesis  (2),  and  Sub-Requires. 
case  Sub-Method.  Follows  from  induction  hypothesis  (2),  induction  hypothesis  (1),  and 
Sub-Method. 


2.  By  case  analysis  on  the  last  rule  used  in  the  <  derivation: 
case  Sub-Row-Perm,  Sub-Row-Width.  Immediate. 

case  Sub-Row-Depth.  Follows  from  induction  hypothesis  (1)  and  Sub-Row-Depth. 
case  Sub-Row-Trans.  Straightforward,  using  induction  hypothesis  (2).  □ 


Lemma  A. 5  (Strengthening  for  sub-brand  judgement). 

If  Z  ok  and  B  C  and  Zq  ok  and  Z  2  Zq  and  B  e  Zq,  then  B  C. 

Proof.  By  induction  on  B  Ex  C. 

case  Sub-Brand-Refl.  Immediate. 

case  Sub-Brand-Trans.  Straightforward  induction. 

case  Sub-Brand-Decl.  brand  B  extends  C  e  Z. 

By  the  non-duplicate  entries  lemma  (Lemma|A.i|l,  Zq  has  only  one  entry  for  B,  therefore 
brand  B  extends  C  e  Zq.  The  result  follows  from  Sub-Brand-Refl.  □ 


Lemma  A.6  (Weakening  for  inherit-ok  judgement). 

If  Zo  ok  and  i-Xg  B  extends  C  requires  D  inherit-ok  and  Z  ok  and  Z  2  Zq  and  B  ^  Z,  then 
Ex  B  extends  C  requires  D  inherit-ok. 

Proof.  By  inversion  on  Exq  B  •••  inherit-ok.  We  proceed  by  considering  each  premise  of 
inherit-ok  and  showing  that  the  same  premise  holds  under  Z. 

1.  C  e  Zq.  By  the  definition  of  set  inclusion,  C  e  Z. 
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2.  D  e  Zq.  Similar  to  above. 

3.  DitC  (Vz  e  Immediate. 


4- 


6. 


7- 


5. 


V  i,  j.  i  i=  j.  iD'.  Ci  Eiq  D'  and  Cj  D',  where  D'  i=  Object. 

Suppose  that  for  some  i  j,  there  exists  D'  ^  Object  such  that  Ci  Ex  D'  and  Cj  Ex  D'. 
But,  by  sub-brand  strengthening  (Lemma|A.5|l,  this  implies  that  Q  Exq  D'  and  Cj  Exq  D', 
which  is  a  contradiction  of  our  initial  assumption.  Therefore,  the  no-diamond  property 
holds  under  Z  as  well  as  Zq. 

Q  requires  £  e  Zo  implies  3k.  Cic^-Lq  E  or  E  (VzcL.zz). 

Since  C  e  Z  and  Z  does  not  contain  duplicate  brands  (Lemma  . 


A.i 


_  the  declarations  of  C 

in  Z  are  the  same  as  those  in  Zq.  Next,  by  sub-brand  weakening  ( Lemma |A.3||,  if  Cfc  Exq  E, 
then  Cic  Ex  E,  and  similarly  for  0^. 

D,- requires  £' e  Zq  implies  3k.  E' or  E'  (Vzel..m).  Similar  to  above. 

V z,  j.  'iq.  mtype^^  [q,  Ci]  -  p  and  mtype^^  [q,  Cj]  -  p'  implies  z  =  j. 

From  this  it  follows  that  for  all  z  ^  j,  ^mtype^^lq,  Ci]  or  imtype^^iq,  Cj].  We  must  show 
that  the  above  holds  under  the  larger  context  Z.  Suppose  that  for  some  z  and  j,  i  j  and 
mtype^iq,  Ci]  -  p  and  mtype^iq,  Cj]  -  p'.  By  Lemma  A. 2  there  exists  D  such  D  t  Object 
and  Ci  Ex  D  and  Cj  Ex  D.  But,  this  is  a  contradiction  of  the  no-diamond  property  shown 
above  (itemQ.  Therefore,  the  required  property  holds  under  Z  as  well  as  Zq.  □ 


Lemma  A.  7  (Weakening  for  internal  judgement). 

If  Zq  ok  and  i-Xq  B.q  internal  and  Z  ok  and  Z  3  Zq  and,  then  \-z  B.q  internal. 

Proof.  Straightforward  induction  on  Exq  B.q  internal.  □ 

Lemma  A.8  (Strengthening  for  internal  judgement). 

If  Z  ok  and  Ex  B.q  internal  and  Zq  ok  and  Z  3  Zq  and  B  e  Zq,  then  Exq  B.q  internal 


Proof.  By  induction  Ex  B.q  internal. 


case  Internal-Base.  Follows  from  the  fact  that  £  e  Zq  and  that  there  is  only  one  entry  for  B  in 
Z  (Lemma|A.i|. 

case  Internal-Inh.  From  the  fact  that  £  e  Zq  and  that  there  is  only  one  entry  for  £  in  Z 
(Lemma [a. i|,  it  follows  that  brand  £(t;  Q)  extends  C  e  Zq  and  q€  Q.  Since  super-brands 
of  £  are  also  in  Z  (Lemma  A. 12  ,  C  e  Zq.  The  result  then  follows  from  the  induction  hy¬ 
pothesis  and  Internal-Inh.  □ 


Lemma  A.9.  If  Z  ok  and  mtype^  [q,  B]  -  p  and  method  C.^(-  •  •)  C  then  \—z  B.q  internal. 


Proof.  Straightforward  induction  on  the  mtype  derivation,  using  the  fact  that  MType-Ext  can¬ 
not  apply.  □ 
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Lemma  A.io  (Weakening  for  m type  judgement). 

If  Zq  ok  and  mtype^^ [q, B)-p  and  Z  ok  and  Z  2  Zq,  then  mtype-^iq, B)  -  p. 


Proof.  By  induction  on  mtype^^  [q,  B)  -  p. 

case  MType-Base.  By  the  definition  of  set  inclusion  and  the  fact  that  well-formed  contexts  do 
not  contain  duplicate  brands  (Lemma  |A.i|,  brand  B[r;...,q  ■  p,...)  The  result  then 
follows  from  MType-Base. 

case  MType-Ext.  Similar  to  above. 

case  MType-Inh. 

(1)  brand  B(t]  Q)  extends  C  e  Zq 

i2)q€Q 

(3)  iextDef^fq,B) 

(4)  3fc.  mtype^^  (q,  Q)  =  p 

By  the  definition  of  set  inclusion  and  the  property  of  no  duplicate  brands  in  a  well- 
formed  context  (Lemma [a. i[),  the  first  two  premises  hold  for  Z.  It  suffices  to  show  that 
3extDef^[q,B).  Then,  by  the  induction  hypothesis,  mtypej^[q,Ck)  -  p  and  the  result  fol¬ 
lows  from  MType-Inh. 


We  are  to  show  3extDef^(q,B).  Either  (a)  an  external  method  family  q  exists  in  Zq  or  (b) 
it  does  not: 


subcase  (a)  method  B.q[. . . )  e  Zq. 

We  have  method  q  e  1.  (by  the  properties  of  set  inclusion).  Since  we  have 
iextDef.^fq,B)  and  methods  must  be  defined  in  a  single  block,  this  yields 
^extDef^[q,B). 


subcase  (b)  method  qt  Zq. 

i-^o  Ck  internal. 


By  Lemma 

A.9 

Lemma 

A.7 

this 

By  Internal-Inh,  i-^o  internal.  By 


Again,  there  are  two  cases:  either  (i)  method  qt'Lor  (ii)  method  q^'L: 


(i) .  Result  follows  from  the  definition  of  extDef. 

(ii) .  Let  decl-type  -  method  D.qiB.q  :  p,...)  and  let  Z  =  I.1,  decl-type,1.2.  Inversion 

on  Zi  decl-type  ok  yields  premise  (4)  of  Tp-Ext-Method:  internal. 

Since  Z  2  Zi,  we  may  use  the  contrapositive  of  strengthening  for  the  internal 
judgement  (Lemma[A.8|,  which  yields  ff  x  B.q  internal.  This  is  a  contradiction 
of  (B),  therefore,  this  case  is  vacuous.  □ 


Lemma  A.ii  (Weakening  for  override-ok  judgement). 

If  Zq  ok  and  i-^o  B.q :  p  override-ok  and  Z  ok  and  Z  2  Zq,  then  1-2;  B.q :  p  override-ok. 
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Proof.  Follows  from  miype  weakening  (Lemma |A.io|  and  subtype  weakening  (Lemma|A.4|.  □ 

Lemma  A.  12  (Super-brands  exist  in  well-formed  contexts). 

If  B  Ex  C  and  Z  ok  then  C  e  Z. 

Proof.  Straightforward  induction  on  Z  ok,  using  inversion  of  decl-type  ok  and  premises  (1)  and 
(2)  of  inherit-ok  in  the  base  case.  □ 

Lemma  A.  13  (Weakening  of  decl-type  ok  judgement). 

If  Zo  ok  and  Zq  i-  decl-type  ok  and 
Z  ok  and  Z  2  Zq  and 

decl-type^ame  ^ 

then  Z  I-  decl-type  ok. 

Proof.  By  inversion  on  Zq  i-  decl-type  ok. 

case  Tp-Brand-Decl.  We  proceed  by  examining  each  premise  and  showing  that  it  holds  under 
Z;  then,  rule  Tp-Brand-Decl  can  be  used  to  derive  Z  1-  decl-type  ok. 

1.  i-^o  B  extends  C  requires  D  inherit-ok. 

Follows  from  weakening  on  inherit-ok  judgement  (Lemma|A.6|. 

2.  Zq  =  Zo,  decl-type. 

Take  Z'  =  Z,  decl-type.  We  have  Z'  ok  since  by  assumption,  Zq  ok  and 
Zq  I-  decl-type  ok;  Sigma -Wf-Decl  then  applies. 

3-  '“z'  ^  fieldTypej-jj  (C). 

Follows  from  weakening  on  subtype  judgement  (Lemma[A.4|. 

4.  q  distinct.  Immediate. 

5.  i-j-/  B.q  :  p  override-ok. 

Follows  from  weakening  on  the  override-ok  judgement  (Lemma|A.ii|. 
case  Tp-Ext-Method.  We  proced  as  in  the  previous  case,  showing  that  each  premise  holds 
under  Z. 

1.  Object.  Immediate. 

2.  C  distinct.  Immediate. 

3.  QEzqB  (Vzel..n). 

Follows  from  sub-brand  weakening  (Lemma |A.3[). 

4.  ffiQ  C.^  internal.  Follows  from  the  contrapositive  form  of  strengthening  for 
internal  (Lemma[A.8|l. 

5.  Zq  =  Zo,  decl-type.  Take  Z'  =  Zq,  decl-type. 

6.  i-j-/  C.q :  p  override-ok. 

Follows  from  weakening  on  the  override-ok  judgement  (Lemma|A.ii|.  □ 


A. 3.  Basic  Lemmas 
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Lemma  A.14  (Declarations  are  well-typed  under  their  containing  context). 

If  Z  ok  and  decl-type  e  Z  then  Z  1-  decl-type  ok. 


Proof.  Straighforward  induction  on  Z  ok,  using  Lemma  A.  13  for  the  base  case. 


Lemma  A.15  (Weakening  for  typing  judgement). 

If  Zq  ok  and  L  i-^o  e :  t  and  Z  ok  and  Z  2  Zq,  then  F  1-2  e :  t. 


□ 


Proof.  By  induction  on  e :  t. 


case  Tp-Var,  Tp-Unit.  Immediate. 

case  Tp-Fun,  Tp-App,  Tp-New-Record,  Tp-Proj,  Tp-Fold,  Tp-Unfold.  Straightforward  in¬ 
duction. 

case  Tp-Subs.  Follows  from  weakening  on  the  subtype  relation  (Lemma [A. 4). 
case  Tp-New-Obj.  By  the  fact  that  declarations  are  distinct  from  one  another  (Lemma  |A.i| 
and  the  properties  of  set  inclusion,  B  requires  •  and  fieldTypej-(B)  =  r.  By  the  induction 
hypothesis,  F  i-j;  Ci  :  t.  By  weakening  on  the  mfype  judgement,  mtype^(q,B)  -  p.  The 
result  then  follows  from  Tp-New-Obj. 


case 

case 

case 


Tp-With.  Similar  to  above. 


Tp-Invoke-Struct.  Follows  from  the  induction  hypothesis  on  the  first  premise,  weaken¬ 
ing  of  the  subrow  judgement  (Lemma[A.4|,  and  Tp-Invoke-Struct. 


Tp-Invoke-Nom.  Follows  from  the  induction  hypothesis  on  the  first  premise,  weakening 
of  the  mtype  judgement  (Lemma  A.io|,  weakening  of  subrow  judgement  (Lemma  |A.4| 
and  Tp-Invoke-Nom. 


case  Tp-Invoke-Super.  Similar  to  above. 


□ 


A. 3  Basic  Lemmas 

This  section  contains  lemmas  used  by  both  progress  and  preservation  proofs. 


A. 3.1  Miscellaneous  Lemmas 

Lemma  A.  16  (Consistency  of  static  and  dynamic  sub-branding). 

If  Z  ok  and  A  :  Z  then  Bi  Ex  B2  iff  Bi  Ea  Pi- 


Proof.  For  the  “if”  direction,  straightforward  induction  on  Bi  Ex  Bi-  For  the  “only  if”  direction, 
straightforward  induction  on  Bi  Ea  B2,  in  both  cases,  using  the  definition  of  A  :  Z  (Def.  3.2 1.  □ 


Lemma  A.17  (Precisifying  object  types). 

If  Z  ok  and  F  \-i  C[e;  n^q) :  t  and  i-z  t  <  B{M),  then 

1.  F  Ex  C[e;n^q):C[n:  p),  where  mtype^iq, C)-~p  and  Ex  C[n:  p)<  B[M],  and 
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2.  n  distinct,  and 

3.  C  requires  •  e  Z. 

Proof.  By  induction  on  the  typing  derivation. 

case  Tp-Subs.  Follows  from  the  induction  hypothesis  and  Sub-Trans. 

case  Tp-Obj.  Immediate  from  premises  of  rule.  □ 

Lemma  A.  18  (Reflexivity  of  sub-row  judgement). 

The  sub-row  judgement  is  reflexive;  i.e.,  T  i-j;  r  :  t  <  r  :  t,  for  all  Z  such  that  Z  ok. 

Proof.  Immediate  from  either  Sub-Row-Perm  or  Sub-Row-Depth.  □ 

Lemma  A.  19  (Reflexivity  and  transitivity  of  method  subtyping). 

The  following  rules  are  admissible: 


Pi  ^  P2  P2  ^  P3 
P<P  Pl<P3 

Proof.  For  the  reflexivity  property,  result  follows  from  Sub-Brand-Refl  and  reflexivity  of  sub¬ 
row  (Lemma|A.i8|.  Transitivity  proof  is  straightforward.  □ 

Lemma  A.20  (Properties  of  valid  overrides). 

If  Z  ok  and  1-2;  B.q :  p'  override-ok  and  B  C  and  mtype^iq,  C)  =  p,  then  p'  <  p. 

Proof.  Straightforward  induction  on  B  Ej  C,  using  inversion  of  the  override-ok  derivation  in 
the  base  case.  □ 


Lemma  A.21  (Sub-brands  have  mtypes  that  are  subtypes). 

If  Z  ok  and  B  Ez  C  and  mtype^iq,  C)  =  p,  then  rntype^^iq,  B)  =  p',  where  \-z  p'  <  P- 


Proof.  By  induction  on  B  E  C. 


case  Sub-Brand-Refl.  Result  follows  from  reflexivity  of  method  subtyping  (Lemma|A.i9|. 

case  Sub-Brand-Trans.  Straightforward  uses  of  induction  hypothesis,  followed  by  transitivity 
of  method  sub  typing  (Lemma[A.i9|. 


case  Sub-Brand-Decl.  B  extends  C 
There  are  four  possible  cases: 

1.  q  is  defined  internally  in  B  with  type  p' .  By  MType-Base,  mtype^[q,B)  -  p' .  Since 
Z  is  well-formed,  by  Lemma  A.14I  the  declaration  of  B  is  well-formed  under  Z.  By 
inversion  on  decl-type  ok,  B.q :  p'  override-ok  (premise  (5)  of  Tp-Brand-Decl).  By 
the  properties  of  a  valid  override  (Lemma[A.2o|,  p'  <  p,  which  is  the  required  result. 


A. 3.  Basic  Lemmas 


137 


2.  q  is  defined  externally  for  B  with  type  p'.  Similar  to  above. 

3.  ^  is  not  defined  in  B.  By  MType-Inh,  mtype^iq,  B)  -  p,  which  is  the  required  result.  □ 


Lemma  A.22  (Zoofcup  implies  mtype). 

If  Z  ok  and  A  :  Z  and  lookup /^[q,  B)  -  e,  then  there  exists  a  derivation  mtype-^iq,  B)  -  p,  for  some 
P- 

Proof  By  induction  on  the  derivation  of  lookup^. 

case  Lookup-Base.  Follows  from  the  definition  of  A  :  Z  and  MType-Base. 
case  Lookup-Ext.  Follows  from  the  definition  of  A  :  Z  and  MType-Ext. 
case  Eookup-Inh.  We  have  lookup i^[q,  Cf)  -  e,  where  B  extends  Q  e  A.  Also,  by  A  :  Z,  we  have 
Cfc  e  Z.  By  the  induction  hypothesis,  mtype-^iq,  Cf)  -  P-  Applying  MType-Inh  yields  the 
required  result.  □ 


Lemma  A.23  (Properties  of  super). 

If  Z  ok  and  A  :  Z  and  super ^(B  as  C)  -  D  then  B^/^D  and  D  Ea  C. 

Proof.  By  induction  on  super ^  [B  as  C)  =  D. 

case  Super-Base.  By  Sub-Brand-Decl,  B  Ea  E).  D  Ea  C  by  premise  of  rule, 
case  Super-Inh.  By  the  induction  hypothesis,  Eic  Ea  D  (where  B  extends  e  A)  and  D  Ea  C.  By 
Sub-Brand-Decl  and  Sub-Brand-Trans,  B  Ea  D,  which  is  the  required  result.  □ 


Lemma  A.24  (No  diamond  inheritance). 

If  Z  ok  and  brand  B  extends  C  e  Z,  then  there  does  not  exist  D  (other  than  Object),  such  that 
Ci  Ex  D  and  Cj  Ex  D  (for  any  i  j). 


Proof  By  Lemma  A.14I  Z  1-  brand  B  •  •  ■  ok.  By  inversion  on  the  decl-type  ok  judgement,  we  have 
Ex  brand  B  inherit-ok  (premise  (1)  of  Tp-Brand-Decl).  Inverting  this  last  judgement  yields 
premise  (4)  of  Tp-Inherit,  which  is  the  required  result.  □ 


Lemma  A.25  (Well-formed  brands  do  not  contain  duplicate  methods). 
If  Z  ok  and  brand  B[r;q'.  p)  ■■■  e  Z,  then  there  are  no  duplicates  in q. 


Proof  Follows  from  Lemma  A. 14  and  premise  (4)  of  Tp-Brand-Decl. 


Lemma  A.26  (Properties  of  well-formed  external  methods). 

If  Z  ok  and  method  B.qiC.q  :'p]el.,  then  we  have  all  of  the  following: 

1.  B^  Object 

2.  C  distinct 


□ 
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3.  QEzB(Vzel..#C) 

4.  ffs  C.^  internal. 


Proof.  Straightforward  induction  on  Z  ok,  using  the  fact  that 
Lemma  A.36|  and  then  applying  inversion  on  this  derivation. 


i-z 


method  ...  ok  (by 

□ 


A. 3. 2  Inversion  Lemmas 

Lemma  A.27  (Inversion  of  the  sub-row  judgement). 

If  Z  ok  and  L  1-2  {ra^  :  <  {rbj  '■  tbj  then  {rbj  £  {ra^  (r^  includes  at  least 

the  labels  in  7b)  and  L  i-x  U,  <  tfo,  for  each  common  label  Va;  -  rb,. 

Proof.  Straightforward  induction  on  the  <  derivation.  □ 

Lemma  A.28  (Inversion  of  subtyping  [expression  and  method  types]). 

1.  If  Z  ok  and  L  i-x  Ti  ^  T2  <  ni  ^  cr2>  then  L  i-x  cri  <  Ti  and  L  1-2  T2  <  cr2- 

2.  If  Z  ok  and  L  1-2  {/ :  t}  <  {A: :  a},  then  L  1-2  :  t}  <  {A: :  a] 

3.  If  Z  ok  and  L  1-2  jJ-X. Ti  <  /iF.  T2,  then  V,X<Y  1- Ti  <  T2. 

4.  If  Z  ok  and  L  1-2  Bi(Mi)  <  B2[M2),  then  L  1-2  Mi  <  M2  and  either  (a)  Bi  E2  B2  or  (b)  there 

exists  some  B2  where  B2  E2  B2  and  Bi  requires  ^ 

5.  If  Z  ok  and  L  1-2  Mi  Ti  <  M2  T2  then  L  1-2  M2  <  Mi  and  L  1-2  Ti  <  T2. 


Proof.  Straightforward  induction  on  each  subtyping  derivation. 


□ 


Lemma  A.29  (Inversion  of  the  typing  judgement). 

1.  If  r  I- Ax:ti.  e :  a  and  rr  <  ffi  ^  a2  then  Ui  <  Ti  and  r,x :  Ti  i-  e :  o'2- 

2.  If  r  I-  (^  =  e  '^1") :  O'  and  rr  <  {A: :  t  then  ei :  r j  for  each  common  label  (i  -  kj. 

3.  If  r  i-fold^jf.re :  a  and  a  <  fiX.r,  then  L  1-  e :  [fxX.rlX]  r. 

4.  If  r  \-Cie;  ria  ^qf'-cr  and  a  <  B[nb  '■  Pb)  then: 

(a)  C£B; 

(b)  r  I-  e :  fieldTypej-  (C);  and 

(c)  ria-Pa  <  nb-Pb>  where  mtype^(qa)  =  p^. 


Proof.  By  induction  on  each  typing  derivation.  Note  that  for  each  case,  the  derivation  ends  in 
exactly  one  of  two  rules,  one  of  which  is  always  Tp-Subs. 


1. 


2. 


Functions.  Straightforward,  using  the  induction  hypothesis  for  case  Tp-Subs  and  the 
subtyping  inversion  lemma  (Lemma  A.28 1  for  case  Tp-Fun. 


Records .  Straightforward  induction,  using  the  sub  typing  inversion  lemma  (Lemma[A.28| 
for  the  base  case. 
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3.  Recursive  types.  Straightforward  induction,  using  Lemma  A. 28  for  the  base  case. 

4.  Object  types.  C(e;  n,- ^  :  cr 


case  Tp-Subs.  Result  follows  from  the  induction  hypothesis  and  Sub-Trans. 

case  Tp-New-Obj.  Follows  from  subtype  inversion,  sub-row  inversion,  and  the  rule’s 
premise  that  C  requires  •  e  Z.  □ 


A.4  Progress  Lemmas  and  Theorem 

Lemma  A.  30  (Canonical  forms). 

Suppose  Z  ok  and  i-z  v-a  and  i-j  a  <r. 

1.  If  T  =  unit  then  v  -  (). 

2.  If  T  =  Ti  ->  T2  then  V  is  of  the  form  Xx'-r'-^.e. 

3.  If  T  =  Bin  :  p)  then  v  is  of  the  form  C[v';  na  ^  qg)- 

4.  If  T  =  {/ :  t}  then  V  is  of  the  form  {k  -  v). 

5.  If  T  =  fj,X.T  then  V  is  of  the  form  fold^  v'. 


Proof.  Straightforward  induction  on  typing  derivations.  □ 

Lemma  A.31  {lookup  defined  on  well-typed  methods  [Lemma 

If  Z  ok  and  mtype^iq,  B)  -  p  and  A  :  Z,  then  lookup i^iq, B]  -  e,  for  some  unique  e. 


Proof.  By  induction  on  mtype^iq, B)  -  p. 

case  MType-Base.  q  is  defined  directly  in  B. 

From  the  definition  of  A  :  Z,  the  rule  Lookup-Base  applies.  Since  brands  do  not  contain 
duplicate  methods  (Lemma[A.25|),  there  is  only  one  applicable  ^  =  e  for  B.  It  now  suffices 
to  show  that  the  rule  Lookup-Ext  cannot  apply,  as  Lookup-Inh  is  already  excluded  (its 
second  premise  does  not  hold). 

Suppose  Lookup-Ext  did  apply.  By  the  definition  of  A  :  Z,  there  is  a  definition  decl-type  - 
method  D.qi...,B.q  :  p',...)  e  Z.  By  Lemma  A. 26  ffs  5.^ internal.  But,  by  assumption. 


q  is  defined  in  B  and  therefore  rule  Internal-Base  applies,  yielding  \-z  B.q  internal — a 
contradiction. 

case  MType-Ext.  From  the  definition  of  A  :  Z,  the  rule  Lookup-Ext  applies.  Since  there  are  no 
duplicate  method  families  ^  in  Z  (Lemma |A.i|,  inversion  on  A  :  Z  yields  that  is  only  one 
such  entry  method  q  ■■■  e  A.  Let  decl-type  -  D.qiC.q :  p)  be  the  definition  of  the  method 
family  q  in  Z.  By  Lemma  A.26|  C  distinct.  By  inversion  on  A  :  Z,  there  is  not  a  duplicate 
entry  B.q  -  e'  in  the  method  family  q  in  A.  Therefore,  there  is  exactly  one  derivation  of 
Lookup-Ext. 
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It  now  suffices  to  show  that  Lookup-Base  does  not  apply,  as  by  inspection,  Lookup-Inh 
does  not  apply.  The  reasoning  for  this  is  similar  to  that  above;  Lemma  p\..26| yields 
B.q  internal,  from  which  it  follows  that  Lookup-Base  does  not  apply. 


case  MType-Inh.  Wehave  CU  =  p,  for  some  Q  where  B  extends  Cjc-  By  the  induction 

hypothesis,  lookup ^[q,  C^)  =  e,  for  a  unique  e.  It  now  suffices  to  show  that  there  does  not 
exist  j  t  k  such  that  B  extends  Cj  and  lookup^[q,Cj)  -  e'.  Then,  the  rule  Lookup-Inh 
then  uniquely  applies,  since  its  premises  exclude  the  other  two  rules. 


Suppose  such  a  j  did  exist,  i.e.,  B  extends  Cj  and  lookup [^[q,Cj)  -  e' . 
{lookup  implies  mtype),  there  exists  p'  where  mtype-^iq,  Cj]  -  p' . 


By  Lemma 


A. 22 


By  Lemma |A.36|  Z  i-  (B(...)  extends  CpC^,... requires  ...)  ok.  Inversion  on  decl-type  ok 
yields  B  extends  Cy,Ci;...  inherit-ok;  i.e.,  premise  (i)  of  Tp-Brand-Decl.  Inversion  on 
this  last  derivation  yields  premise  (7)  of  Tp-Inherit,  which  assumes  that  j  k.  As  this  is 
a  contradiction  of  the  assumption  above,  this  yields  the  required  result.  □ 


Lemma  A.32  (Well-typed  objects  have  well-typed  simple  names). 

If  r  I-  Civ;  n^q) :  t  and  t  <  B(M)  and  Ua  e  M,  then  there  exist  and  pa  such  that  Ua^q^^ 
n^q  and  mtypeiqa,  C)  =  Pa- 

Proof.  By  induction  on  :  i- 

case  Tp-Subs.  Immediate  from  induction  hypothesis. 

case  Tp-New-Obj.  By  the  form  of  the  rule,  t  =  C(7zTp),  where  mtype(q,C]  -p.  LetM  =  Um  ■  Pm- 
By  subtype  and  sub-row  inversion  (Lemmas|A.28|and|A.27|l,  Tim  £  n.  We  have  Ua  e  Um-  By 
the  properties  of  the  subset  relation,  e  n.  Let  k  be  the  index  of  in  n.  Finally,  taking 
Pfc  as  Pa  yields  the  required  result.  □ 


Lemma  A.33  (Transitivity  of  the  super  judgement). 

If  Z  ok  and  A  :  Z  and: 

1.  B£aA; 

2.  A  Ea  C  and  A  4  C; 

3.  C  t  Object;  and 

4.  super ^  (A  as  C)  =  D,  for  the  unique  result  D, 
then  super ^[B  as  C)  =  D,  for  the  unique  result  D. 

Proof.  By  induction  on  B  Ea  A. 
case  Sub-Brand-Refl.  Immediate. 

case  Sub-Brand-Trans.  We  have  B  E  A'  and  A'  E  A,  for  some  A'.  By  Sub-Brand-Trans,  A'  E  C. 
Applying  the  induction  hypothesis  to  the  sub-derivation  A'  ^  A  yields  super (A'  as  C)  =  D, 
for  some  unique  D.  Taking  this  fact  and  applying  the  induction  hypothesis  to  B  E  A'  yields 
the  required  result. 
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case  Sub-Brand-Decl.  We  have  B  extends  A.  First,  we  will  show  that  there  does  not  exist  D' 
such  that  D'  E  C  and  B  extends  D'  (this  will  satisfy  the  first  premise  of  Super-Inh).  Sup¬ 
pose  such  a  D'  did  exist.  Then  B  extends  A,  D'  where  D'  E  C.  But,  by  assumption,  A  E  C 
and  C  ^  Object,  so  this  would  violate  the  no-diamond  property  (Lemma.  A.24 1.  Therefore 
such  a  D'  cannot  exist.  Taking  A  as  £jt,  we  have  super ^[B  as  C)  =  D  by  Super-Inh. 


We  must 
super ^[Ej  as  C) 


next  show  that  there  does  not  exist  Ej  such  that  B  extends  Ej  and 
D",  then  we  will  have  shown  that  the  result  of  super j^iB  as  C)  is  unique. 


Suppose  such  an  Ej  did  exist.  By  Lemma  A. 23  we  have  Ej  E  D"  and  D"  E  C.  From  this  it 
follows  that  Ej  E  C  (by  Sub-Brand-Trans).  But,  this  would  again  create  a  diamond  (with 
a  brand  other  than  Object  at  the  top),  as  we  have  assumed  B  extends  A,  Ej  and  Ej  E  C  and 
we  have  A  E  C.  □ 


Lemma  A.34  (Conditions  under  which  super  is  defined). 

If  Z  ok  and  A  :  Z  and  B  Ea  C,  where  B  i=C  and  C  t  Object,  then  super ^[B  as  C)  =  D,  for  a  unique 
result  D. 


Proof.  By  induction  on  B  Ea  C. 


case  Sub-Brand-Refl.  Vacuous,  as  we  have  assumed  BtC. 


case  Sub-Brand-Trans.  Be  A  AeC 
There  are  two  subcases: 


1.  B  -  Aor  A  -  C.  Result  follows  from  the  induction  hypothesis,  as  this  gives  a  sub¬ 
derivation  B  E  C. 


2. 


B  t  A  and  Ai=  C.  By  the  induction  hypothesis  on 
unique  D.  Taking  this  along  with  the  assumptions 
gives  the  required  result. 


AeC,  super j^iA  as  C)  =  D,  for 


B  ^  A  and  A  E  C,  Lemma  A. 33 


case  Sub-Brand-Decl.  B  extends  C  e  A 

Take  D  as  C.  By  Sub-Brand-Refl,  C  E  C.  The  rule  Super-Base  then  applies.  It  now 
suffices  to  show  that  there  does  not  exist  D'  such  that  B  extends  D'  and  D'  E  C,  as  the 
result  of  super ^  (B  as  C)  is  then  unique.  The  non-existence  of  such  a  D'  follows  from  the 
no-diamond  property  (Lemma[A.24|l,  since  we  have  C  E  C  and  we  would  have  D'  □ 


Lemma  A.  3  5  (Progress:  expressions). 

If  Z  ok  and  •  e :  t  then  either  e  is  a  value,  or,  for  any  A  such  that  A  :  Z,  there  exists  e'  such 
that  e  I — >A  e'. 

Proof.  By  induction  on  e :  t,  with  case  analysis  of  final  rule  used, 
case  Tp-Unit,  Tp-Fun.  Immediate, 
case  Tp-App.  Straightforward. 
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case  Tp-Subs.  Result  follows  from  induction  hypothesis. 


case 


case 


Tp-New-Record.  e -(£  -  e) 

By  the  induction  hypothesis,  each  e,  either  steps  to  some  e[  or  is  a  value.  If  any  ei  steps, 
then  the  rule  E-Record  applies.  Otherwise,  the  entire  expression  is  a  value. 


case  Tp-Proj.  e-ei.(ic 

By  the  induction  hypothesis,  either  e\  steps  to  some  e'^  or  it  is  a  value.  If  it  steps  to  e[,  then 
E-Proji  applies.  Otherwise,  if  it  is  a  value,  by  canonical  forms  (Lemma[A.3o|l  ei  has  the 
form  [k  -  v)  and  E-Proj-Val  applies. 


Tp-New-Obj.  e-B[ei,n^q) 

By  the  induction  hypothesis,  ei  steps  to  some  e\  or  it  is  a  value.  If  it  takes  a  step,  then 
E-Obj  applies.  If  it  is  a  value,  then  then  e  is  also  a  value. 


case  Tp-With.  e-e\  with  n-q 

By  the  induction  hypothesis,  either  e\  is  a  value  or  it  steps  to  some  e\.  If  it  steps,  then 
the  rule  E-With  applies.  Otherwise,  by  canonical  forms  (Lemma[A.3o|,  e\  has  the  form 
C[v;  n'  ^  q').  Then,  the  rule  E-With-Val  applies. 

case  Tp-Invoke-Struct,  Tp-Invoke-Nom.  e  -  ei.m  ei :  B(AI) 

In  either  case,  by  the  induction  hypothesis,  either  ei  steps  to  some  e[  or  it  is  a  value.  In 
the  first  case,  E-Invoke  applies.  Otherwise,  by  canonical  forms  (Lemma[A.3o[),  ei  has  the 
form  Civ;n^  q).  It  suffices  to  show  that  mbody^im,  C,n^q)  is  uniquely  defined;  the 
rule  E-Invoke-Val  then  applies. 

case  Tp-Invoke-Struct.  m-n 


By  Lemma  A. 32  we  have  (a)  q  e  q  and  (b)  mtype^(q,  C)  =  p,  for  some  q 


and  p.  From  (b).  Lemma p\..3i|yields  that  lookup^(q,C)  is  uniquely  defined.  From 
this  and  (a),  the  rule  MBody-Simple  applies.  Since  MBody-Qual  is  not  applicable, 
mbody  is  also  uniquely  defined. 


case  Tp-Invoke-Nom.  By  Lemma  A. 31  lookup^(q,C]  is  uniquely  defined.  The  rule 
MBody-Qual  then  applies  and  mbody  is  therefore  uniquely  defined. 

case  Tp-Invoke-Super.  e  =  ei.C.super.<5' 

Either  ei  is  a  value  or  it  evaluates  to  some  e\.  If  it  evaluates,  the  rule  E-Super-Invk  applies. 
Otherwise,  by  canonical  forms  (Lemma  A. 30 1,  e\  has  the  form  B'[v;  n  By 


Lemma  A. 34  there  exists  a  unique  D  such  that  super ^jB'  as  C)  =  D.  By  Lemma  A. 23 
B'  Ex  D.  Precisifying  the  object  type  (Lemma  A. 17  >  gives  us  B'[---)  :  B'[M),  and  by  Sub- 
Obj,  B' [■■■)■.  Dm. 

From  the  premise  of  the  Tp-Invoke-Super,  we  have  mtype.^[q,C)  -  p.  Also,  by 


Lemma  A. 23  D  Ex  C.  By  Lemma  A. 21  mtypoyjq,  D)  -  p'  (where  p'  <  p).  Taking  this  fact 
together  with  B'(  -)  :  D(M),  by  Lemma  A. 31  lookupi^[q,D)  is  uniquely  defined.  Then, 
E-Super-Invk-Val  applies. 


case  Tp-Fold.  e  =  fold,:ei 
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By  the  induction  hypothesis,  either  ei  takes  a  step  or  it  is  a  value.  If  it  takes  a  step,  then 
the  rule  E-Fold  applies.  Otherwise,  e  itself  is  a  value. 

case  Tp-Unfold  e  =  unfold^x.r 

By  the  induction  hypothesis,  either  ei  takes  a  step  or  it  is  a  value.  If  it  takes  a  step,  then 
the  rule  E-Unfold  applies.  Otherwise,  it  is  a  value  v  of  type  /iX.r.  By  canonical  forms 
(Lemma[A.3o|,  v  has  form  fold^x.r  O-  so  the  rule  E-Unfold-Fold  applies.  □ 


Theorem  A.i  (Progress  theorem  for  programs  [Theorem|3.2[). 

If  Z  ok  and  Z  1-  p  ok,  then  one  of  the  following  cases  holds: 

1.  p  is  a  value;  or 

2.  for  any  A  such  that  A  :  Z,  there  exist  p'  and  A'  such  that  p  \  A  1 — >  p'  \  A'. 

Proof.  By  case  analysis  of  the  form  of  p. 
case  p  =  Z  >  ded  in  p. 

Either  E-Brand-Decl  or  E-Ext-Decl  applies, 
case  p-'L>e. 

The  result  follows  from  the  progress  lemma  for  expressions  (Lemma|A.35|  and  E-Expr.  □ 


A. 5  Preservation  Lemmas  and  Theorem 

Lemma  A.36  (Weakening  for  T). 

If  Z  ok  and  E  i-x  e :  t,  then  E,  x :  cr  i-x  e :  t 

Proof.  Straightforward.  □ 

Lemma  A.37  (Substitution). 

If  Z  ok  and  E,x:  cr  i-x  ei :  t  and  E  i-x  62  ^  cr  then  E  i-x  {ea/xjei :  t. 


Proof.  Straightforward  induction  on  typing  derivations. 


□ 


Lemma  A.38.  If  Z  ok  and  C  Ex  D,  then  fieldWithReq^lC)  <  fieldWithReqj;(D). 


Proof.  Straighforward  induction  on  C  E  D.  For  the  base  case,  by  Lemma  A. 14  we  have  \-z 
brand  C  extends  D  ok.  Inversion  on  this  judgement  yields  premises  (1)  and  (3)  of  Tp-Brand- 
Decl,  which  give  the  required  result.  □ 


Lemma  A.39  {mtype  is  a  function  [Lemma [3^). 

If  Z  ok  and  mtype^iq,  B)  -  pi  and  mtype^iq,  B)  -  p2,  then  pi  =  p2. 


Proof.  By  simultaneous  induction  on  the  two  mtype  derivations,  making  use  of  the  fact  that 
MType-Inh  excludes  MType-Base  and  MType-Ext. 
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case  MType-Base,  MType-Base.  Immediate  from  the  property  of  non-duplicate  internal 
method  names  (Lemma |A. 25 |l. 

case  MType-Base,  MType-Ext.  Vacuous:  external  methods  may  not  override  internal  meth¬ 
ods.  That  is,  Lemma  A. 26  gives  if  2  B.q  internal,  but  MType-Base  assumes  q  &  B,  i.e., 
i-s  internal. 

case  MType-Ext,  MType-Ext.  Immediate  from  the  properties  of  unique  method  external 
method  families  and  non-duplicate  external  method  definitions  (Lemmas |A.i|and|A.26|. 

case  MType-Inh,  MType-Inh.  We  have  B  extends  Q  e  Z  and  B  extends  C2  e  Z.  Let 
mtype^iq,  Ci)  =  pi  and  mtype^iq,  C2)  -  pi- 

But,  we  will  now  show  that  Q  =  C2.  By  Lemma  A. 36  Z  1-  B  ok.  By  inversion  on  this 


derivation,  we  have  premise  (1)  of  Tp-Brand-Decl,  i.e.,  i-x  B  inherit-ok.  Finally,  by 
inversion  on  this  last  derivation,  we  have  premise  (7)  of  Tp-Inherit,  which  requires  that 
mtypeiq)  derivations  do  not  exist  for  two  distinct  superclasses. 

Now,  by  the  induction  hypothesis,  pi  =  pz-  The  result  then  follows  from  MType-Inh.  □ 


Lemma  A.40  (Result  of  lookup  is  well-typed  [Lemma [3^). 

If  Z  ok  and  A  :  Z  and  mtype^iq,  C]  -  N=>r  and  lookup /^[q,  C)  -  eo,  then 
this :  cTc,  fields :  oy  1-2;  eo'-T. 

for  some  Uc  and  ay  such  that  C(A)  <  Uc  and  fieldWithReq^fC)  <  ay. 


Proof.  By  induction  on  lookup ^[q,  C). 


case  Lookup-Base.  By  the  definition  of  A  :  Z,  must  be  defined  internally  in  C  with  some  type 
p  -  N=^r.BY  MType-Base,  mtype^iq,  C)  -  N^r  (for  the  unique  result  N^t,  since  by 


Lemma  A.25[  internal  method  names  q  are  distinct  from  one  another).  Finally,  from  the 
definition  of  A  :  Z  (Def.l3.3ll,  we  have: 

this :  C(Ar), fields  :fieldWithReqj-(C)  i-x  eo'-r, 
which  is  the  required  result. 

case  Eookup-Ext.  By  the  definition  of  A  :  Z,  (y  must  be  defined  externally  for  C  with  some 
type  p  -  N  ^  r.  By  the  properties  of  well-formed  external  methods  (Lemma  A.26|, 
ff  C.q  internal.  By  the  definition  of  internal,  q  is  not  defined  internally  in  C,  so  the  rule 
MType-Base  cannot  apply.  By  inspection,  the  rule  MType-Ext  applies  and  mtype^iq,  C)  - 
A  =>•  T.  Finally,  Lemmas|A.i  and|A.26]  there  is  only  one  method  family  q  and  there  cannot 
be  a  duplicate  entry  for  C;  therefore,  the  result  N^t  is  unique. 

From  the  definition  of  A  :  Z  (Def.  ^1,  we  have: 
this :  C[N]  i-x  eo  ■  t. 

Applying  weakening  for  T  (Lemma[A.36|  gives  the  required  result. 


case  Eookup-Inh.  By  the  premises  of  the  rule,  q  is  not  defined  internally  or  externally  on 
C.  Also,  C  extends  D  e  A  and  lookup^[q,D)  -  oq.  By  Lemma  [A.22[  the  derivation 
lookup i^[q,D)  implies  that  there  exists  a  derivation  D  ::  rntype^^iq, D)  -  p,  for  some  p  and 
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some  T)  that  does  not  contain  MType-Req.  By  MType-Inh,  D2  -  mtype^iq,  C)  =  p,  where 
D2  does  not  contain  MType-Req.  By  Lemma  A. 39  p  is  the  same  as  the  result  of  the  as¬ 
sumed  mtype  derivation;  that  is,  p  =  A  t. 

By  the  induction  hypothesis,  we  have: 
this :  Od,  fields :  oy  i-i  eo'-r, 

for  ad  such  that  DiN)  <  ad  and  ffy  such  that  fieldWithReq^ (T>)  <  oy. 

It  remains  to  show  that  (a)  C[N)  <  ad  and  (b)  fieldWithReqj;  (C)  <  ay.  Result  (a)  follows 


from  Sub-Brand-Decl,  Sub-Obj,  and  Sub-Trans.  Result  (b)  follows  from  Lemma  A. 38 
(i.e.,  fieldWithReq^lC)  <  fieldWithReqj;(D))  and  Sub-Trans.  □ 


Lemma  A.41.  If  Z  ok  and  C  B  and  B  requires  D  e  Z,  then  either  C  Ex  D  or  C  requires  D',  for 
D'  such  that  D'  Ex  D. 


Proof.  Straightforward  induction  on  C  Ex 
the  base  case. 


B,  using  Lemma  A. 14  and  inversion  of  inherit-ok  in 

□ 


Lemma  A.42  (Preservation:  expressions). 

If  Z  ok  and  T  \-z  e:r  and  A  :  Z  and  e  1 — >a  e',  then  T  \-z  e'  ■■  t. 


Proof.  By  induction  on  e :  t. 


case  Tp-Var,  Tp-Unit,  Tp-Fun.  Vacuous;  e  does  not  evaluate. 


case  Tp-App.  Straightforward,  using  Lemma  A. 37 


case  Tp-Subs.  e:a  a<r  ei — >^e' 

By  the  induction  hypothesis,  e' :  a  and  the  result  follows  from  Tp-Subs. 


case  Tp-New-Record.  The  only  evaluation  rule  that  applies  is  E-Record.  We  have  1 — 

By  the  induction  hypothesis,  The  result  then  follows  from  Tp-New-Record. 

case  Tp-Proj.  e  ■■  {ki :  T; 

There  are  two  possible  evaluation  rules  that  apply: 

subcase  E-Proji.  Result  follows  from  the  induction  hypothesis  and  Tp-Proj. 

subcase  E-Pro j2.  {£  j  -  Vj  1 — ^a  Vk 

By  typing  inversion  (Lemma|A.29|),  we  have  {£j  :  rj  <  {ki :  and  Vk  '■  Tk> 

which  is  the  required  result. 

case  Tp-New-Obj.  e  -  Biep,  n^q)  ei'-r'  ei  1 — 

The  only  evaluation  rule  that  is  applicable  is  E-Obj.  By  the  induction  hypothesis,  e'j  :  r' . 
The  result  then  follows  from  Tp-New-Obj. 
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case  Tp-With. 


BrequiresDeZ 

JihtM  n/,  distinct  3C'  e  {B,D}.  mtype-^[qij.,C') :  pt,.  (VzeL.n) 
r  i-ei  with  q^,.  :  B(M,  nz,. :  pz,. 


There  are  two  possible  evaluation  rules  that  apply: 

subcase  E-With.  Result  follows  from  the  induction  hypothesis  and  Tp-With. 


subcase  E-With-Val. 

C{v']na^qa)  with  n^^q^  i — C{v']  mergeirii,  ^  q^,  Ha  ^  qj] 


Pi  =ei  =  C(P';7TFT^  Vi:B[nm-Pm)  M^Um-pm 

Precisifying  the  type  of  Pi  (Lemma[A.i7|  yields: 

(1)  Pi  :C(na:pJ 

(2)  C[na  :  Pa)  <  BiUm  ■  Pm),  where  rntype^iq^,  C)  =  p^,  and 

(3)  C  requires  •  e  Z. 

By  inversion  on  the  subtyping  derivation  (2)  (Lemma[A.28|l, 

(i)  C  E  B  and 

(ii)  ■  Pa  —  •  Pm 

By  sub-row  inversion  on  (ii)  (Lemma|A.27|: 

Paj  <  Pm,  for  each  commom  label  Haj  =  rim^ 

Um  £  fT’U 


Let  n^ji  be  the  set  of  labels  that  are  in  Ua  but  not  in  nt,  (that  is,  n^i  -  ria  -  fih, 
where  is  set  difference).  By  the  definition  of  merge,  mergeirih  ^  q^^,  ria  ^  q^)  - 

^a’  ^^a'- 

Let  p  =  C(p';  mergeitib  ^  qi,,  Ua  ^  From  above,  v  -  C(p';  Ub  ^  qb,  ^a'  ^ 

We  are  to  show  that  p :  B[M,  nb  ■  pb),  i-e.,  p  -Birim  :  pm,  Ub  ■  Pb)- 


By  premise  (5)  of  Tp-With,  for  all  i  e  L.n,  either  (a)  mtype^[qij.,B]  :  pz,.  or  (b) 

A.41  since  C  E  B  and  C  requires  •,  C  E  D.  For 


3k.  mtype^iqij.,Dic)  ■  Pbf  By  Lemma 
each  i,  in  either  case,  by  Lemma |A. 21 


rntype^iq^  ,  C) :  p'^.,  where  p'^,.  <  pb^. 


Applying  Tp-Obj,  p  :  C[nb'-  p'j^,^,^/  '■  Pa')  By  premise  (3)  of  Tp-With,  rib,  rim  are 
disjoint.  From  this,  we  can  conclude  Hm  E  Since  we  have  p^f  <  pmi  for 

^a'.  -  Sub-Row-Width  and  Sub-Row-Depth,  fVTV  ^  ^m  '■  Pm-  Also, 

by  Sub-Row-Depth,  rib  •  p'l,  ^  nz, :  pb-  Finally,  by  Sub-Row-Perm,  rib  ■  p'l,, •  Pa'  ^ 
nm  •  pm,  nb  '■  Pb,  which  is  the  structural  part  of  the  required  result.  Finally,  since 
C  E  B,  the  result  follows  from  Sub-Obj  and  Tp-Subs. 
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case  Tp-Invoke-Struct. 

Ti-e\-BiM)  n.N=>r€M  M<N 

r  I-  ei.n  :  T 

There  are  two  possible  evaluation  rules  that  apply: 

subcase  E-Invoke.  Result  follows  from  the  induction  hypothesis  and  Tp-Invoke. 


subcase  E-Invoke-Val. 


3  unique  Pq-  mbody^(n, C,n^q]  =  Bq 
C[v'-,n'^q).n  1 — {C(p';  n  ^  ^)/this,  p'/fields}  eo 


e-V\.n  ei-Vi-C[v'-,n^q)  Vi'-BiM) 

By  precisifying  Vi  (Lemma[A.i7|l: 

Vi  :  Cin  :  p), 

and  C[n  :  p)  <  B[M)  and  C  requires  •,  where  mtype(^  -  p.  Applying  Lemma  A. 29 
(inversion  on  the  typing  derivation)  to  Pi :  Cin  ■  p),  we  have: 
v' :  fieldTypej-(C). 

It  suffices  to  show  that: 
this : Tc, fields : Ty  \-eo-T, 

for  some  Tc  and  r y  where  C[n :  p)  <  Tc  and  fieldTypej-lC)  <  Ty,  the  result  then  follows 
from  the  substitution  lemma  (Lemma[A.37|. 

By  MBody-Simple,  mbody^  in,C,n^  q)  -  lookup^iq,C),  where  n^q  e  W^Tq. 
From  above  (result  of  Lemma  A. 17  1  mtype^iq,  C]  -  p.  Let  p  -  N'  =>  r'. 


Applying  Lemma  A. 40  we  have: 
this :  (Tc,  fields :  oy  1-2;  eo'-r, 

for  some  ffc  and  cry  such  that  C[N')  <  Oc  and  fieldWithReqj.(C)  <  ay. 

Recall  from  above  that  C  requires  •.  From  this,  it  follows  that  fieldWithReqj- (C)  = 
fieldTypej-(C)  and  we  can  take  ay  as  Ty  from  above. 

It  now  suffices  to  show  that  (a)  C [n :  p)  <  C [N')  and  (b)  r'  <  r;  then  we  may  take  ac 
as  Tc  and  apply  Tp-Subs.  By  subtype  inversion  (Lemma  A.28|  on  C[n  ■  p)  <  BiM) 
we  have  n :  p  <  M.  By  Tp-Sub-Row,  n :  p  <  N.  Also,  since  we  have  n :  A  ^  t  e  M,  by 
subrow  inversion  (Lemma|A.27|  we  also  have  N'  <  N  ^r.By  subtype  inversion 
(Lemma  A.28|  on  this  last  derivation,  N<N'  and  r'  <  r,  the  latter  satisfying  (b). 

Finally,  by  Sub-Row-Trans,  n :  p  <  N'.  Tp-Obj  yields  Cin :  p)  <  C(A')  which  is  the 
required  result. 


case  Tp-Invoke-Nom.  e-ei.q 

r  HPi  :R(M) 


mtypej_  iq,B]  =  N^r 


M<N 


r  l-Pi.^:  T 
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case 


There  are  two  possible  evaluation  rules  that  apply: 

subcase  E-Invoke.  Result  follows  from  the  induction  hypothesis  and  Tp-Invoke. 
subcase  E-Invoke-Val. 

3  unique  Cq-  mbody^iq,  C,n<^q)  =  eg 
C{v']n‘^  q).q  i — {C{p';  n  ^  ^)/this,  p'/fields}  eg 


e-Vi.q  ei-  Vi-  C[v']n^  q)  Vi'-BiM] 

This  proof  is  very  similar  to  that  of  case  Tp-Invoke-Struct,  E-Invoke-Val  above. 
The  main  difference  is  the  reasoning  for  obtaining  a  derivation  mtype^iq,  C)  -  N'  ^ 


By  precisifying  Vi  (Lemma[A.i7|l: 

Vi-.C[n:p), 

and  C(n :  p)  <  B(M)  and  C  requires  •.  Applying  Lemma[A.29|(inversion  on  the  typing 
derivation)  to  Vi  ■■  C[n  :  p),  we  have: 
v' :  fieldTypej.(C). 

It  suffices  to  show  that: 
this  :  Tc,  fields  :  Ty  I- Pq  :  T, 

for  some  Tc  and  t f  where  C[n :  p)  <  Tc  and  fieldType5;(C)  <  Ty,  the  result  then  follows 
from  the  substitution  lemma  (Lemma[A.37|l. 

By  a  straightforward  inversion  on  the  derivation  mbodyi^[q,C,---),  we  have 
lookup [^[q,  C)  -  eg-  From  this,  Lemma[A.22|there  is  a  derivation  mtype^iq,  C)  -  N'  ^ 
r',  for  some  N'  =>-  r'. 


Applying  Lemma  A.40  we  have: 
this :  ac,  fields :  oy  i-s  eg  ■  r, 

for  some  ffc  and  ay  such  that  CiN')  <  Cc  and  fieldWithReq^lC)  <  oy. 


Recall  from  above  that  C  requires  •.  From  this,  it  follows  that  fieldWithReq^ (C)  = 
fieldTypej.(C)  and  we  can  take  ay  as  Ty  from  above. 


It  now  suffices  to  show  that  (a)  C (n  :  p)  <  C [N')  and  (b)  r'  <  t;  then  we  may  take  ac 
as  Tc.  By  inversion  on  the  subtype  derivation  C[n  :  p]  <  B[M]  above  (Lemma[A.28|, 
we  have  n  :  p  <  M  and  C  Ex  R  (since  C  requires  •).  By  Sub-Row-Trans,  n :  p  <  N. 


Recall  that  mtype^iq,  B)  -  N  and  mtype-^iq,  C)  -  N'  ^  r'.  By  Lemma  A. 21 


N< 


N'  and  r'  <r  (the  latter  satisfying  (b)  above).  Taking  this  together  with  n  :  p  <  N  and 
applying  Sub-Row-Trans,  Sub-Obj  and  Tp-Subs,  we  have  C[n :  p) :  C[N'),  which  is 
the  required  result. 


Tp-Invoke-Super.  There  are  two  possible  evaluation  rules  that  apply: 

subcase  E-Super-Invk.  Result  follows  from  the  induction  hypothesis  and  Tp-Invoke- 
SUPER. 
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subcase  E-Super-Invk-Val. 

3  unique  D.  super j^[B  as  C')-D  3  unique  eo-  lookup ^[q,  D)  -  bq 

C[v' ■,ir^Tq).C. super. q  1 — >a  {C[v;  n  ^  ^)/this,  p'/fields}  eo 


e  I — e' 

e  -  Pi-C'-Super.^ 
B  requires  C'  e  Z 


Vi  -  C[v']n^  q) 


Vi'.BiM) 

T  M  <N 


mtype^iq,  C')  -  N-- 
By  Lemma[A.23|  C  E  D  and  D  E  C'. 

By  Lemmap\..2i|  since  D  E  C',  we  have  mtype^ iq,  D)  -  N'  ^r',  where  N'  ^  r'  <  N  - 


r"  < 


T.  Again  by  Lemma  A. 21  since  C  E  D,  mtype^(q,  C)  =  N  r  where  N 
N'  =>  r' .  Applying  subtyping  inversion  to  these  judgements  (Lemma[A.28|,  subrow 
inversion  and  transitivity  yield  N  <  N"  and  t”  <  r. 

Recall  that  we  have  lookup ^iq, D)  -  bq  and  mtype^iq,D)  -  N'  ^  r' .  Applying 
Lemma  A.40  we  have  this  :  cTc,  fields  :  ffy  Bq  :  r,  for  some  Oc  and  oy  such  that 


D[N')  <  Oc  and  fieldWithReqj; (D)  <  oy. 

From  C  E  D  and  N”  <  N,  Sub-Obj  yields  C{N”)  <  D{N'y,  by  transitivity,  C{N”)  <  Oc- 
By  Lemma  A. 38  fieldWithReq^^fC)  <  fieldWithReqj;(D),  which  by  transitivity  yields 
fieldWithReqj;  (C)  <  ffy. 

By  the  subsitution  lemma  (Lemma[A.37|,  e  ■■  r.  Finally,  since  r"  <  r,  Tp-Subs  yields 
the  required  result. 


case  Tp-Fold.  The  only  evaluation  rule  that  applies  is  F-Fold.  The  result  follows  from  the 
induction  hypothesis  and  Tp-Fold. 

case  Tp-Unfold.  There  are  two  possible  evaluation  rules  that  apply: 

subcase  E-Unfold.  The  result  follows  from  the  induction  hypothesis  and  Tp-Unfold. 


subcase  E-Unfold-Fold. 

Straightforward,  using  typing  inversion  lemma  (Lemma|A.29[). 


□ 


Theorem  A.2  (Preservation  theorem  for  programs  [Theorem|3.3|). 

If  Z  ok  and  Z  e  p  ok  and  A  :  Z  and  p  \  A  1 — >  p'  \  A',  then  there  exists  a  Z'  such  that  (a)  Z'  ok 
and  (b)  A'  :  Z'  and  (c)  Z'  e  p'  ok. 

Proof.  By  case  analysis  on  the  derivation  Z  e  p  ok. 
case  Tp-Decl-Ok. 

®  decl :  decl-type  ®  decl-type^^^g  ^  Z  ®  Zq  e  decl-type  ok 
®  Zo,  decl-type  e  decl  body-ok  ®  Z  3  Xq  ®  Z,  decl-type  e  p'  ok 

Z  E  Zo  >  decl  in  p'  ok 
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By  E-Brand-Decl  and  E-Ext-Decl,  p  \  A  i — >  p'  \  IS.' .  Let  Z'  =  Z,  decl-type. 

By  premises  (3)  and  (5),  Zq  i-  decl-type  ok  and  Z  2  Zq.  By  weakening  on  Zq  (Lemma[A.36|, 
Z  I-  decl-type  ok.  This,  together  with  premise  (2),  yields  Z'  ok,  which  is  part  (a)  of  the 
required  result. 

Part  (c)  of  the  required  result,  Z'  1-  p'  ok  is  immediate  from  premise  (6). 

To  prove  part  (b).  A'  :  Z',  we  case  analyze  the  form  of  decl-type. 

subcase  Brand  declaration. 

decl  -  brand  B{Mi) :  t/  =  et  ”)  extends  C  requires  D 

decl-type  -  brand  B(a]q'.  M  ^  t)  extends  C  requires  D 
A'  =  IS,B[q  -  e]  extends  C 

Let  Zq  =  Zo,  decl-type.  By  assumption,  Zq  i-  decl  body-ok.  Inversion  on  this  deriva¬ 
tion  yields  (by  Brand-Decl-Body): 

(i)  fieldTypej;/  [D)  -  o' 

(ii)  this :  B(M;), fields :  a  a  a'  i-j-/  a  :  t,,  for  all  i  e  l..n 

It  suffices  to  show  that  derivations  (i)  and  (ii)  hold  under  the  larger  context  Z',  as 
then  Delta-Wf-Brand  yields  the  required  result. 

By  the  properties  of  set  inclusion,  Z  2  Zq  implies  that  Z'  2  Zq. 

Since  Z'  ok,  there  are  no  duplicate  brands  in  Z'  (Lemma[A.i|.  Therefore,  item  (i)  has 
the  same  result  under  context  Z'  (i.e.,  o'). 

For  item  (ii),  we  use  the  fact  that  Z'  ok  (proved  above  for  part  (a)  of  the  theorem) 
and  apply  signature  weakening  for  expression  typing  (Lemma[A.i5|.  This  yields 
this :  B(M;), fields :  fieldWithReqj. (5)  i-x  Ci :  Xu  for  all  i  e  L.n, 
which  is  the  required  result. 

subcase  External  method  declaration. 

Similar  to  above;  inversion  on  H'^decl-typehodLy-ok  yields  the  sole  premise  of  Exx- 
Method-Body  (which  is  similar  to  (ii)  above,  except  the  special  variable  fields  is  not 
bound  in  E.  The  result  follows  from  the  properties  of  set  inclusion  and  Delta-Wf- 
Method. 

case  Tp-Expr-Ok. 

The  rule  E-Expr  is  the  only  rule  that  applies,  i.e.,  e  1 — s' ■  By  the  preservation  lemma 
for  expressions  (Lemma[A.42|,  i-Xq  e' :  t.  Since  A'  =  A,  take  Z'  =  Z;  the  result  then  follows 
from  Tp-Expr-Ok.  □ 


Theorem  A.3  (Type  safety). 

If  Z  ok  and  Z  1-  p  ok  and  A  :  Z,  then  either  (1)  p  is  a  value  or  (2)  p  |  A 
and  A'  where  A'  :  Z'  and  Z'  ok  and  Z'  1-  p'  ok. 


p'  I  A',  for  some  p' 
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Proof.  Follows  from  progress  and  preservation  theorems  ( Theorems |A.i|and|A.2[).  □ 

Corollary  A.i  (Method  lookup  always  succeeds  in  well-typed  expressions). 

If  Z  ok  and  i-x  v.m  :  t  and  A  :  Z  then  v.m  \ — for  some  unique  e' . 

Proof.  Follows  from  progress  lemma  on  expressions  (Lemma|A.35|l  and  the  sole  premise  of  the 
method  evaluation  rule  E-Invoke-Val,  which  requires  that  the  result  of  method  body  lookup 
(mbody)  be  uniquely  defined.  □ 

Theorem  A.4  (Typechecking  is  modular  [Theorem|3.i|). 

Typechecking  top-level  elements  declarations  decl  is  modular.  That  is,  typechecking  such  ele¬ 
ments  only  involves  examining  the  signatures  on  which  decl  statically  depends. 

Proof.  Follows  from  the  fact  that  top-level  elements  are  typechecked  under  their  declared  con¬ 
text  Zq.  The  only  rules  that  examine  the  entire  linearized  program  context  Z  are  Tp-Decl-Ok 
and  Tp-Expr-Ok,  in  the  premise  Z  2  Zq.  This  step  is  analogous  to  a  linking  phase  in  which  im¬ 
ported  declarations  are  resolved.  Since  checking  set  inclusion  does  not  involve  typechecking  of 
any  kind,  this  check  adheres  to  the  definition  of  modular  typechecking.  □ 
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Appendix  B 

Empirical  Study  Details 


B.i  Subject  Programs 


Program 

Version 

Ant 

1.7.0 

antlr 

2.7.6 

Apache  collections 

3.2 

Areca 

5.5.3 

Cayenne 

2.0.4 

Columba 

l.ORCl 

Crystal 

3.3.0 

Drjava 

20080904-r4668 

Emma 

2.0.5312 

freecol 

0.7.3 

hsqldb 

1.8.0.4 

HttpClient 

3.1 

jEdit 

4.2 

JFreeChart 

1.0.0-rcl 

JHotDraw 

7.0.9 

jruby 

1.0.1 

jung 

1.7.6 

LimeWire 

4.13.0 

log4j 

1.2.15 

Lucene 

1.4 

OpenFire 

3.4.2 

pit  collections 

20080904-r4668 

pmd 

3.3 

poi 

2.5.1 

quartz 

1.5.2 

Smack 

3.0.4 

Struts 

2.0.11 

Tomcat 

6.0.14 

xalan 

2.7.0 

Table  B.i:  Version  numbers  of  empirical  study  subject  programs 
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B.2  Subjective  Criteria 


In  Section  |4.3.2|  I  enumerated  the  number  of  cases  where  it  could  be  “useful”  to  general¬ 
ize  the  parameter  types  of  a  particular  method.  To  determine  this,  I  asked  two  questions. 
First,  does  the  inferred  parameter  type  S  generalize  the  abstract  operation  performed  by  the 
method  (as  determined  by  the  method  name)?  For  example,  generalizing  the  List  parameters  in 
ListUtils. intersection  does  appear  to  generalize  the  abstract  operation  of  taking  the  intersection 
of  two  sequences.  Second,  does  it  seem  likely  that  there  would  be  multiple  subtypes  of  S?  For 
example,  in  Crystal  I  found  that  there  were  two  methods  of  the  IBinding  interface  that  were  often 
used,  and  I  was  informed  by  the  developers  that  it  was  conceivable  that  they  would  replace  the 
use  of  Eclipse  binding  objects  with  an  application-specific  representation. 


In  Section  4.5.2I  I  tabulated  the  number  of  methods  in  a  common  method  group  that  had  “the 
same  meaning.”  To  determine  this,  I  used  javadoc  when  available;  when  it  was  not,  I  examined 
the  body  of  the  method  to  determine  the  operation  being  performed. 
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